Posted by Brian @ 3:35 pm on February 25th 2007

Why offshore programming is a waste of money

I’ve now lost count of the number of folks I’ve met who have selected an offshore company to develop software for them and have the project either fail or be substantially flawed. There must be people who have had good results, but I haven’t met them.

The appeal is seductive – get your software developed for a tenth the hourly price of a local developer. Yet the many people I’ve spoken with who have hired offshore software programmers now regard their investment a total loss. After reviewing the results of several offshore projects, I’m so annoyed that I have to write about it.

So why does outsourcing fail? I can think of a few reasons.

It’s tempting to say that the quality of offshore software engineering isn’t up to par, but I don’t think that’s the case. There are plenty of awful programmers in the United States, and I’m sure there are extremely talented engineers in India, Russia, East Europe, China, Indonesia and other outsourcing hot spots around the globe.

I believe the platform has an impact on the results, since all of the offshore disasters I can remember were done under the Microsoft .NET framework or similar proprietary software. Some offshoring must be done with open source software, so I’ll leave the open vs. closed discussion for another day.

Some people might say the client is to blame for not being experienced enough in software development. I can’t agree with that, since many developers (including OpenSourcery) successfully complete work with non-technical clients.

I think the actual reasons are less subject to argument.

Reason 1: Language barriers
Having fluency in a language often isn’t enough when sophisticated concepts are being discussed. One needs to be native born to fully grasp the metaphors, cultural references or unusual terms that get used by clients to describe requirements. This is particularly the case with those who have a light technical vocabulary but a great idea and the business acumen to make it work.

Reason 2: Extreme time zone issues
I’ve been a part of many, many successful projects for clients 3,000 miles away. I’ve even had good luck with employees working at those distances as well. However, communicating with another party 9+ hours off of your local time zone isn’t feasible. If you’re lucky, there might be a one hour window that is only mildly inconvenient for both parties to schedule a conference. That doesn’t cut it. During all phases of development rapid, easy communication is vital to project success. An exchange that takes two minutes between local parties can take 48 hours to resolve with people on the other side of the globe. Let’s take an example — requirements change on a project, this should be expected. Say the client needs a feature added and another removed to stay on budget. An email is sent to an offshore development team explaining the change. When they wake up hours later, they’re certain to have questions – perhaps the feature impacts other areas of the software, or the full scope isn’t clearly understood. The offshore team replies, but the client is now sleeping. The next day, the client sends a clarification. In the meantime, the offshore group might have stopped work entirely as they await the response from the client. A few of these and suddenly the project is a month overdue.

At the end of the day I don’t see how these issues can be overcome. No matter how cheap the hourly rate may be, the only metric that matters is the end result. Time and again clients have come to us saying “we just spent X dollars on offshore programming but we’re unhappy with the result. Can you help us?” Yes, we can and do help, but for the original budget we often could have built the project ourselves from scratch. I hate to be the bearer of bad news – to have to tell a client that their money was wasted offshoring. I wish I, or someone like me, could have spoken with them before they made the decision to go offshore, because they would have been far better off leveraging existing open source software with a local team from the outset.