Offshore software development: the reasons why not

Of all the numerous cold calls I get, inquiries from potential offshoring partners lead the pack. Their main pitch, of course, is that I can lower my development (or support, or QA) costs by leveraging offshore labor at a third or less of domestic rates. This argument is tends to be all the more compelling the further up the management chain you go: CEOs and boards of directors will often ask why we haven’t dealt with cost issues by adopting an offshore development approach.

Although I can see both sides of the argument, this post will focus on the negatives. I’ve come to a very firm stance on the topic of offshoring: the risks and the hidden costs tend to far outweigh the potential advantages. To be sure, I may have come to that stance largely because I’ve rarely, if ever, worked in a company where I felt the necessary prerequisites were in place to be able to even consider offshoring as a viable option. More on that later.

The lure of offshoring depends on a number of implicit underlying management assumptions that in my view amount to myths or misunderstandings. To ascribe to these myths is to go against decades of lessons learned in the trenches of software development. At the risk of being perceived as setting up a straw man argument, here is a list of just a few of these fallacies:

Fallacious assumption #1: Development is the vital core of a project
To the non-technical executive outside the process, the code produced by a development project is the most tangible, usable outcome, so it’s the main deal, hands down. Everything else is secondary.

Offsetting the fallacy: in the cosmic pie chart that represents the various aspects of software development, it’s actually quite well-known and accepted that the actual coding itself is a relatively small slice, compared to the work of analysis, design, implementation, testing, and so on. The bulk of just about any project consists of arduously hammering through business requirements and then design, almost always in a close back-and-forth with the business stakeholders. Think you can create an up-front, “throw it over the transom” type of design? That assumes you can easily lay out what you really want. And in hydra-headed large organizations, that simply isn’t realistic: how you construct the system depends vitally on that back-and-forth, that ongoing communication, that juggling of desired features versus feasibility of delivery. As one blog comment pointed out, “most of the time you have a half-baked design when you start coding.” To swerve a cliche: it takes a village. Requirements gathering, design, and coding just aren’t easily siloed as completely separate activities.

Fallacious assumption #2: Near-term cost is paramount, and the main part of that cost is development
It’s hard, at the executive level, to resist the luster of staff costs dropping to an ostensible third of what in-house projects cost. 33 cents on the dollar? What’s not to like about that?

Offsetting the fallacy: consider the medium or long-term effects. Substantial rework, months or even years down the road, can often ensue from having had a basic mismatch of requirements to delivery. Moreover, when delivery of working code is considered to be the main goal, lots of other concerns get effectively diminished or even totally ignored: maintainability, scalability, flexibility. Anyone can easily show you two examples of working code for even a trivial function, much less a complex system, and demonstrate that one solution is inarguably much “worse” along these multiple dimensions than the other. I’m not saying that offshore-produced code is necessarily always worse, but I am saying that the focus when offshoring tends to be just on the delivery of working code, so entropy pushes things in that direction. It’s also well known that the effort of reading, maintaining, and updating a set of code far exceeds the cost of initially building it.

Even aside from those concerns of quality, offshoring often comes with a set of executive blinders about the other costs of taking that approach. I watched one company I worked for enthusiastically and with great fanfare outsource its development to India, because of the lower cost. Next thing I knew, we were shipping them expensive servers for development and test, buying software licenses to support their work, procuring bandwidth back to the US, juggling source code control, and seeing members of our in-house staff take lengthy trips over there to monitor what was going on. I won’t even go into the numerous other logistics problems that arose. Did anyone add up those costs? Of course not. Another general motto of mine: “Take all the costs into account.

Fallacious assumption #3: Staff continuity isn’t a major concern
This fallacy basically reflects the executive viewpoint that code development can be black-boxed: what matters is just getting the code, which is the commodity that counts. Code need to be fixed later? That’s simply another task, to be allocated to the appropriate resource.

Offsetting the fallacy: over the long term, a cohesive team (i.e., one with some measure of continuity) will be vastly more productive than a fragmented team; constant staff changes and upheaval eventually tend to show up in the balance sheet because things end up costing more. The act of reading and maintaining code from scratch, especially poor code, is a less than trivial undertaking, and always takes longer than having it handled by a team that has some measure of staff continuity. By its nature, offshore staffing is essentially out of your sight, and it’s very hard to gauge the effects of turnover. And of course, you’re just focused on getting working code out of them anyway; whether it’s the same team this week as last is relatively of little concern. I’ve seen offshore teams have significantly greater turnover than domestic teams, even during the Internet-crazy years in America.

In summary: initial coding is easy. Requirements gathering and design are hard. Communication is hard. Maintenance is hard. Staff continuity is hard. So offshoring is a seductive thing: it makes the easy part easier and cheaper, but at the cost of making the hard parts much harder and riskier.

As Martin Fowler pointed out, “offshore development is very fashionable, but it’s still too early to really understand its true strengths and pitfalls. Certainly anyone doing it because they think they’ll get cost savings similar to the rate differences is seriously deluding themselves.”

In my next post, I plan to seemingly reverse myself somewhat, and explain why you should nonetheless mold your organization to be capable of leveraging offshore or other outside development.

Comments

  1. VICTOR singh says

    Here’s my take,

    The disadvantages/risks presented by you , have already been known and worked out since long. The process of outsourcing is there since a decade now and if there were any serious risks/implications , it would have met its natural demise by now.

    Most of the outsourcing are done to companies which are CMM levele 5 ( a standard devised by the US itself) and they meet higher standards than the development environment in the outsourcer comany itself.

  2. No, I disagree with each of your points. For one thing, offshoring IS falling out of fashion to some degree, for various reasons (e.g., political, social) not limited to the disadvantages I covered in my post. See, for example, “CFOs say Offshore Outsourcing to Decline“, from BusinessWeek. And your point about CMM level 5? Sure, I don’t disagree that there are many fine companies to outsource to, but that misses the entire point of my post: it’s NOT about development alone.

Trackbacks

  1. […] analysis document for each project? That’s an excellent place to make sure that all the costs are taken into account, including non-capitalizable elements such as maintenance.  Again, “no […]

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Mastodon