I want my job to go to India

With high speed internet connections, a developer working in Raleigh, North Carolina and one working in Pune, India are virtually indistinguishable. Do you know where all the people you exchange email with actually live? Probably not. It's even hard to tell if they're working in the office or at home any more. Yet the developer in the US (or France or Japan or ...) may enjoy 4 times the salary of the one in India (or Russia, or China or ...) because our cost of living is so much higher. Unless we justify that salary, it's not sustainable. So how do we do that?

A colleague told me today that 70% of her time is spent maintaining the old version of the software as opposed to working on the next version. By maintainence I mean duplicating customer reported problems, fixing bugs, creating hot fixes and service packs,  tweaking performance to address complaints, and so forth. No matter how much time you spend testing, often these late problems involve load that was heavier, or data that was bigger, or operations that were more complex than you could come up with in house. Multi-threaded applications are especially problematic as often you'll have an intermittent timing-sensitive problem that won't show up at all until certain conditions are met.

Does this sound familiar? You have a long list of innovative ideas and features that you'd love to put in the next version, but you're unable to find the time. Management promises that you'll be given time as soon as these maintenance things let up. But they never let up. Management promises to clear your schedule, to restrict maintenance to part of the team and let you have some breathing space. But then the next day a high priority gotta-have-it-now defect comes in. Experienced, highly qualified and highly paid developers become firefighters, running from one emergency to another. Meanwhile the remote teams, with no such baggage, get the new projects and growth opportunities, and produce quicker results because they can do it full time.

This is incredibly frustrating, and I think it's exactly backwards. I want to switch roles.

We propose what we call "sustainability teams". As soon as a product version gets to a certain stage, whether it's beta or release candidate or early release or first ship, responsibility for that version is transfered completely from the local development team to the remote sustainability team. The sustainability team learns the code and handles all bug fixing and tweaking duties for the rest of that version's lifecycle. It's hard but well defined work, a good way to build up experience. And, importantly, they get to send feedback on anti-patterns and problem areas they discover to the designers of the next version.

Time zone differences actually work in your favor here. Communication is limited by physical and temporal separation, forcing the sustainability team to dig in and learn how everything works themselves rather than going down the hall and interrupting the development team. One team can come up with a list of questions at the end of their work day which will be waiting when the next team reports for work the next day Then the second team could take all the time the need to have the answers ready for the first team when they come back to work.

Meanwhile those frustrated but talented developers and architects who are just chomping at the bit to work on the cool new stuff are set free to deliver innovation and customer value nearly 100% of the time.

So what do you think? If you're doing this already, how is it working out?