
After finding an article that made the case right in the title, that follow-the-sun (FTS) application development simply “doesn’t work” I shrugged it off, accepting the fact that a lot has changed; especially with the wider acceptance and ramped up functionality of the cloud since 2005, when the article was written. Yet, in the article itself the author does soften his stance, stating that FTS “rarely” works, and offers tips for those who “must do it.”
While an article nine years in our past can easily be forgiven for its inaccurate assumptions about FTS development, I found another from just 2011 claiming that “follow the sun is a failure.” What I find really interesting about both of these articles is that they each only point out the difficulties in working with multiple time zones, different sets of national holidays, and even scheduling lunch times.
I’m not saying these aren’t actual challenges that must be addressed in order for FTS to succeed, but with the number of immensely successful global enterprises who are practicing some level of FTS today, these are hardly reasons to turn down the undeniable business advantages of FTS. Doubling the amount of work done each and every day outweighs the burden of having to do creative scheduling with your teams’ lunch breaks. Come on.
Even as a huge believer in FTS, there is a much larger challenge behind it – no matter how little press it may get in various technical trade publications. One of the most difficult aspects of FTS is not just collaborating over the phone, or Skype, or what have you, but being able to provide your geographically dispersed teams with access to the most recent, accurate, and sharable complex dev/test environments – so that the version they’re working around the clock to release isn’t just focused on speed, but on quality.
Another common complaint of geographically removed testing teams is that of latency. A slow connection often results in very slow execution of test suites, whether that is done manually or as part of a regression test. If a performance testing team has to use a remote desktop computer to run scenarios, the response times they get back won’t even come close to resembling production-level times for end customers. These latency problems can persist even in many cloud dev/test scenarios, as the system under test may still live back overseas with the development team.
I think this is perhaps why people were so skeptical of FTS back in 2005, or even in the aforementioned case in 2011—though that article in particular was written by a group of nearshoring supporters. Just three years ago, FTS offered zero promise of increased software quality along with the reduced time to market that everyone was trying so hard to achieve. With agile development being obviously well established in 2011, enterprises knew that the customer would always want their product faster, but the number of bugs making it to production absolutely had to be reduced, and FTS alone was not the silver bullet to accomplish this.
Fast-forward to today, and increased software quality, on top of speed, delivered by dispersed teams is not just an option. It will soon be expected, if it isn’t already. What supercharges FTS to address this challenge? We call this “follow-the-moon” development. Dev/test teams can now not only copy, share, and collaborate within multi-tier environments – these environments, no matter how complex, can be spun up in the next global cloud-based instance in a data center located nearest to the next team in the SDLC.
Nobody ever said that collaborating across the globe is easy. At times, it’s hard enough to collaborate within your own four walls, but it’s necessary—especially in software development, and definitely at the enterprise level. I wonder if follow-the-sun developers wouldn’t have had so much fear back in the day if delivery speed hadn’t been its only selling point. By making higher quality just as much of a priority, and giving remote teams the wherewithal to make it happen, following the moon makes following the sun a lot less scary.
Disclaimer: This article was written by a guest contributor in his/her personal capacity. The opinions expressed in this article are the author’s own and do not necessarily reflect those of CloudWedge.com.