An Always On discussion thread. Hold on to your IDEs, American programers: the Russians are coming, the Russians are coming. And the Chinese. And the Indians. And the Irish. I wrote:

If you can move work to the next building because of IM, email, file sharing, SCM, etc., you can move it a thousand miles.

The questions should be:

1. What work is very hard to move?
2. What advantages can we create that will be hard to follow?
3. What limitations of remote work can we exploit?

My gut reaction is to force jobs to stay here. My head knows that doesn't work well. So the challenge is how to move up, do better, and justify a ten-fold premium over market rates.

You don't export the requirements process, the warmth of high touch service, the intimate understanding of local and industry culture and behavior. That work remains bound to the constantly evolving local domain.

But instead of the handoff going to construction engineers across the room, the customer-aligned tasks go to Irkutsk or wherever the market dictates.

This means, of course, that those who collect requirements must do a much better job, produce clearer and more specific functional specs, test requirements documents for usability and the prevailing criteria for quality, manage shorter iterations, and conduct more rigorous acceptance testing.

The new integration costs and risks are real and substantial, especially across language, culture, legal, financial and political boundaries. If two Houstonians can make communication mistakes, you know it is more difficult when working through translators (surprise surprise but most people don't speak, read, or write English at all, let alone fluently). And culture-centric ideas like courtesy and privacy vary across industries and generations, let alone regions. All parties have currency risk and in some places material poltical and safety risks (work interruptions or delays because of violence, war, government corruption, or other things that happen in the U.S.).

But the separation of user/customer relationship from engineering/construction creates value. It gives freedom to shop for the best partners you can trust. To bid for world class performers in niche specialties for the strategic parts of your project. To make your customers' biases and assumptions explicit, perhaps for the first time. To get more satisfying tradeoffs between scope, schedule, budget, quality and risk.

This looks good for those who buy software development services. Prices "rationalized", quality varied but improving with experience.

How will this affect those who market packaged software to consumers? To businesses?

What career advice would you give a US programmer with ten years' experience? A compsci student in Mexico City?

What knowledge, skills, and abilities will the new offshore software brokers need?

What would an insurer want to know before selling you a completion bond for offshore work?

What process might buy you a sustained competitive advantage as a London game development firm?

p.s. The author of the initial post has financial ties with the AO operators. This isn't disclosed in the post. Be up front, please.

p.p.s. More gripes about AO's design (courtesy of prock+jaffe creative):

1. Comments don't have permalinks.Add permalinks, dudes!
2. Comments aren't listed in chronological order. Topics in reverse chron, Comments in chron order. Have you ever tried to follow a thread from the wrong direction? Argh!  
3. No RSS feed for comment threads. Feed me!
4. Site not accessible to the visually impaired. Pass the Bobby test!
5. Rewrites html, destroying lists, html entities, and link attributes. Let me express myself! 
6. Member profile pages don't show all of a person's posts and comments. They should.
7. Don't call posts "blogs" when they are posts.
8. Enable trackback.
9. Human readable urls, please.

p.p.p.s. What roles should blogs and wikis play in coordinating work across national boundaries?