Offshore Development

Offshore development provides a case study for applying XP's values, principles, and practices outside their "sweet spot," the small team sitting together.

I don't like the political and racial overtones of the word "offshore": high-paid white people taking advantage of low-paid dark people and then complaining about "them" taking "our" jobs. "Offshore" implies an imbalance of power, the kind of imbalance that can easily derail software development. I use the term "multi-site" here because XP applies similarly to all geographically dispersed teams.

There are lots of reasons to run a project at multiple sites. Salary differential is only one of these reasons. The database people may be in Toronto and the telecom people in Denver. No matter the reason for considering multi-site development, it always comes down to a business decision: weighing whether the waste created by not sitting together is more than offset by other advantages.

The values of XP are just as suited to multi-site development as they are to teams that sit together. Embrace feedback more tightly because of the natural isolation created by distance. Nurture communication more because of the unavailability of face-to-face, full-spectrum interaction. You'll have to work harder to achieve simplicity because you won't have as many chances for serendipitous discovery of excess complexity. Courage is just as important as it is in any other setting. Respecting everyone on a distributed team is even more important because of differences in culture and lifestyle.

Some of the practices will have to be modified for multi-site projects. For example, planning may have to occur more frequently than weekly to maintain a sense of conversation and to avoid situations in which one site dictates what another site must do. Beware of abandoning practices just because they seem difficult. The single code base is more important as a point of connection in multi-site development than when sitting together. Work to overcome whatever technical obstacles arise to keep the team working together on the same program.

When it comes to principles, the principle of mutual benefit is the one that bears most on the whole question of multi-site development, especially when talking about jobs being shifted to other sites. The most beneficial outcome for everyone involved is well-paying jobs (relatively speaking) for programmers everywhere and delighted customers who are willing to pay for much more software because it is so much more valuable. Jobs aren't going in search of low salaries. Jobs are going in search of integrity and accountability. If integrity and accountability can better be supplied by a separate company many time zones away, customers will pay the necessary price in difficult communication to get them. If the software industry learns to create more value at lower cost, the increase in demand will more than make up for the temporary loss of jobs in any one location.

In high-cost-base areas, improved efficiency, integrity, and accountability are imperative for survival. The days of one hundred expensive contractors without accountability working on one project are numbered. The same project will be done with ten efficient and accountable programmers or it will go elsewhere. To maintain technical employment in high-cost areas, dramatic improvement is necessary. High-cost-base teams need to focus on high-leverage projects, where the strength of direct communication is most valuable, improving their efficiency so overall costs are on par with doing a similar project elsewhere.

To compete, low-cost-base teams need to increase the value they create too. The technical and marketing advantages of Taylorist improvement programs like the Capability Maturity Model have nearly run their course. Just because you can afford to throw lots of bodies at a problem doesn't mean that is the most profitable way to solve it. Organizations addicted to high labor counts need to gradually reduce their team sizes while increasing throughput.

Here are two scenarios for the future of global software development. In the first, high-cost-base countries try to stop the clock, using politics to allow them to program as usual. Low-cost-base countries have no incentive to improve. Software development stagnates.

In the second scenario, programmers worldwide strive to eliminate software development waste in all its many forms. Businesses find many new uses for a new generation of reliable, effective, and cheap software. The global market for software booms. All countries employ more programmers than a decade before.

Improvement is not a foregone conclusion. Software development could stay on its current path of creeping increments. Without dramatic improvement, though, the global market for software will stagnate as more attractive investments are found in manufacturing and biotechnology. To encourage software development as a craft and a business through the next fifty years, I hope that programmers everywhere will accept the challenge of producing much more valuable software. I believe the expanding market will more than make up for losses in any one location because of increased efficiency and multi-site development.