Outsourcing is not a new topic especially when it comes to Software Engineering. I remember at the beginning of my own career ; the dinosaurs Dinosaur
represented by the mainframe applications and the developers that maintained them. Overwhelmingly Cobol/CICS applications , some of the applications were already a generation old (a human generation that is). Though these applications ran business critical functions, they were not in active development or even active maintenance until the Y2K hysteria took hold as the year 2000 approached.
Taking the little maintenance that was needed to keep the applications operational and packaging them for support overseas with cheaper labor made sense unless of course you were one of the Cobol developers who quickly saw their opportunities dry up. Anyway, with little to no change, tightly controlled operational environments, well defined and documented interfaces, few public facing expectations from mass market consumers and little competition, moving support and maintenance halfway around the world had minimally discernible effect on reliability and correctness of the systems and in many if not most instances had the attendant positive impact of reducing cost.

Fast forward to the world of today and the past decade with the ubiquity of the Web as we know it. Even though a website is more then it’s visual design (sorry Designers) just think of what the rate of change is for the typical website. The domains may stay the same but the user experience is constantly mutating and websites, save for portals have a life-time measured in months, not years. With this type of change, bifurcating development/design/product between far flung timezones creates challenges that though ameliorable, come at tremendous high costs that wash out almost all of the desired “cost” benefit of outsourcing to a longer unit labor rate locale. For anyone that has ever worked on a website, the idea that a visual design is ever final is a mirage. Instead the comps (when you have those) are a development starting point. As the development proceeds and the site takes on sufficient mass, constant revisiting of how the development site looks, feels and operates in a semi real environment drives what changes need to be made to the previous “final” set of design/product requirements. Try to manage this scenario when for example you have perhaps 2 hours of overlap between India and the Eastern Time zone of the United States which during part of the year is 10.5 hours difference. Though the changes come from realtime, usually co-located folks interacting with the current state of the site, the folks remote who are usually the development team are not part of that interaction. Before they can actually adapt they need to reset and understand what the changes are about. Given the small daily overlap between widely divergent timezones , you introduce a large amount of latency as the overlap is used to recalibrate an understanding of what the site is supposed to do now and then you have to wait another day to see how good the understanding was based on the work product from the remote team while you were sleeping.

Next Installment - What Of Web Development can benefit from Sourcing remotely.