There’s still many differences of opinion, both within the general enterprise software world and within ThoughtWorks, about the costs and benefits of using offshore development. The reason why most people look to offshore is to reduce costs, noting the significantly lower rates that you find from offshore vendors. However it’s foolish to look only at rates. Rates are only one component of costs, and in any case you have to look at the entire return on investment. Most people in the software industry know, or should know, that productivity differences between developers are far greater than salary differences – and even the rate differentials offered by offshore aren’t necessarily greater than that. Offshore work also introduces extra costs and risks that may offset the rate differential.
The biggest consequence is the effect on communication. Offshore makes communication harder both due to the distance, which makes it difficult to meet face to face, and the timezone offset. Both of these increase the likelihood of building the wrong functionality as miscommunications occur over requirements. While techniques such as using ambassadors tries to reduce it, there’s still going to be some effect. Also the distance between development and business also reduces the motivation of the development team,since they have no personal relationship to build on.
Of course a high ceremony organization that uses documents as the primary communication mechanism will not suffer as much from this. Essentially their communication has already taken all the damage from lack of direct contact, so the offshore effect is less notable. Agile methods try to restore the direct contact in order to improve communication. Our experience is that even if an agile approach suffers from the communication difficulties of offshore, it’s still better than a documentation-driven approach.
Another trend may work to help with this problem. Increasingly companies are moving other business process functions offshore. If a company moves its accounting function to India, then software to support them can be built in India more easily than it could be in the west. If this kind of movement of business work offshore continues, then Indian development could become the onshore alternative.
Another benefit of offshore that’s coming up is the use of 24 hour development to reduce time to market. The benefit that touted is that by putting hands on the code base at all hours of the day, functionality gets written faster. I must admit this seems a somewhat bogus argument to me, since I don’t see what adding people does in India that it wouldn’t do by adding them to the onshore team.
The nugget in the 24 hour development idea is that despite the tech slowdown it’s still not easy to get talented developers. So often you can’t get enough talented developers in the onshore location, so an offshore team is valuable for their talent rather than any lower cost.
Among all these differences my point of view is clear: I’m sitting on the fence!
The Future of Offshore and Agile
As I write this, offshore development is very fashionable, but it’s still too early to really understand its true strengths and pitfalls. Certainly anyone doing it because they think they’ll get cost savings similar to the rate differences is seriously deluding themselves. Some people talk about all software development moving to the third world in the same way that the steel industry did, others think that after a period of fascination the offshore industry will dry up. My crystal ball just shows me what’s in front of me, in a slightly distorted way.
One conclusion is clear, anyone who thinks that onshore developers will triumph because they are more skilled is very wrong. We’ve found that we can hire just as talented developers in India as we can in North America and Europe.
The weak spots of offshore development come from culture and distance with the business. Because agile development works best with close communication and an open culture, agilists working offshore feel the pain much more than those using plan-driven approaches. But it’s still less pain than the plan-driven methods themselves!
We may never really understand the pros and cons offshore development. Software development is an activity who’s output is impossible to measure. As such we’ll never have hard numbers to prove one approach better than another. What we will see is growing qualitative feedback on the benefits of agility and offshore development – these qualitative assessments will determine if either, or both, will survive.