Why We Don’t Offshore Product Development (Part 2)

Apologies for the gap between posts, I’ve been pre-occupied with a new release and a system problem we had to sort through.  It’s always fun diagnosing and working around bugs in platform software (in this case Sun’s Java 1.4.2); thank goodness Java can be reverse-compiled.

In any case, this is a follow-up to my previous post, in which I described why offshoring doesn’t save as much money as advertised (“Hire world-class Java developers for only $20 per hour!”).  The real-world savings are much less - if any - as the savings are eroded by additional onshore overhead, lower offshore productivity and high offshore wage inflation.

Even more importantly, we found that offshore development is inherently unfit for building true Software-as-a-Service applications, which is what this blog is about.

But before I get into that, I promised to describe our experience with offshoring product development.

Over a few years, we worked with a couple of offshore providers for several projects, and found some success when 1) we could specify very exactly what was needed, 2) there wasn’t a lot of need from the offshore team to communicate with onshore personnel for clarification, and 3) there was a fair bit of work to do (i.e., person-years of effort).

Based on those successes, we decided to work with an offshore partner for development of a new product module, and the project met the above constraints nicely.  We evaluated a dozen providers and chose a medium-sized provider with great customer references, experience in our technologies, and a focus on agile software product development.

The relationship started well, as the offshore project team managers spent several months in our offices reviewing through our application, architecture, design and coding guidelines, and the new module’s requirements.  When the development effort started offshore, we dedicated three people from our development group to support the 15-person offshore team, including our chief architect.

Even this level of oversight (1 onshore person for every 5 people offshore) wasn’t enough, however, as the development effort suffered from delays and missing functionality.  We took over testing and through months of detailed feedback, we were able to work with the offshore provider to get the module completed.

Then the relationship entered the realm of what I call “shenanigans” - the offshore provider wanted to raise rates by over 30%, and they said there were a bunch of hours that they “forgot” to record and bill months earlier.

So the relationship ended badly, but a worse outcome came later when we delved into the code to add some additional features.  Even with a lengthy up-front ramp-up period and our code review oversight during the project, the delivered code overall was worse than our most junior onshore developer would create.  Since then, we’ve rewritten much of the module to be more consistent with our architecture and frameworks and design patterns.

Now, some of this can be chalked up to a poor offshore provider, and there are certainly examples of successful offshored software development projects.  However, I keep in contact with many offshore providers and SaaS firms, and I don’t think the results for what we needed as a SaaS provider would have been fundamentally different with another provider.

At the same time as this project, we had also hired additional onshore developers with terrific results, and so outcome of the offshore project stood in stark contrast with our highly successful growing onshore team. In examining the offshore project after the fact, it was clear that we can build better software, faster, at far higher internal quality, for the same cost in Denver than we can with an offshore partner.

How is this possible?  Well, the unique needs of Software-as-a-Service applications are simply inconsistent with offshore software development.

This post is getting too long, so in the next posts I’ll detail these bullet points about SaaS software development that make offshoring untenable:

• High responsiveness
• Internal code consistency
• Customer-collaborative product development
• Far lower maintenance effort
• System engineering
• Value and speed to market