Offshoring is no silver bullet

Hardly a day goes by when i don’t get a call or e-mail from an overseas company offering outsourced IT services, particularly software development. Just today, an e-mail popped into my inbox that read: “Would you like to save up to 80 percent on your software development costs?” The e-mail went on to tout the highly intelligent labor force in China and how this particular firm’s software development processes “ensure delivery of high quality software on time and within budget.” Sounds great, but I don’t think any such guarantees exist in the real world, regardless of where the development work is done.

Any successful software project I’ve worked on has shared two qualities: a high degree of direct interaction between the development team and the end-users, and a high degree of agility in the team’s methodology. The not-so-successful projects have been of the “deliver the spec and we’ll crank out the code” variety — the kinds of projects typically associated with overseas outsourcing. You might be able to offshore if you are a commercial software vendor with a dedicated product manager. But I have my doubts about this approach in corporate IT, where the core business isn’t software development and specs are always in flux.

Whenever I hear about any new way to make software development an order of magnitude easier, cheaper, faster, or better, I’m reminded of Frederick Brooks’ essay “No Silver Bullet: Essence and Accidents of Software Engineering.” Most, if not all, of what Brooks wrote in 1986 in his paper rings true today. Brooks insists that software development is difficult, and no tool, approach, or methodology can fundamentally change that:

“The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract in that such a conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed.

“The hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems.

“If this is true, building software will always be hard. There is inherently no silver bullet.”

I think overseas outsourcing of software development is simply the latest silver bullet. If you accept Brooks’ assertion that building software is inherently difficult, adding cultural and time zone differences seems daunting. Compare Brooks’ words to the conventional business wisdom about IT jobs headed overseas in a recent Economist piece: “The bulk of [IT job] exports will not be the high-flying jobs of IT consultants, but the mind-numbing functions of code-writing.” The idea that building software is “just writing code” oddly persists in many business circles. This is misguided and is sure to lead to pain and frustration for any company that rushes into overseas outsourcing.

After all these years, Brooks’ writing stands the test of time. Will the present conventional wisdom in the business press about the viability and ease of outsourcing “mind-numbing” code-writing seem relevant or visionary 18 years from now? I doubt it.