Offshoring: The Self-Inflicted Wound
Their vision is built on two blind spots and two personality abnormalities that enable them to miss a pair of truths that couldn't be any more obvious to an objective observer.
Cultists believe that if they can just offshore development, they can make cost-effective projects even if they can't bring themselves to reform their sloppy development practices.
I have dealt with five significant projects in the last six years that involved development, IT or help-desk staff who were not physically located where the project was focused.
In all but one case, the developers were not located in the same neighborhood as either the people who would eventually use the system or the team with expertise in the business processes involved.
Every single one of these projects cost significantly more than it should have, more than it would have cost if the project directors insisted on paying for the most expensive, actually talented "overpaid" developers in the United States.
The projects end up being inefficient uses of resources (even if they had ever captured the original discounted pricethe primary motivator) for two inevitable reasons: proximity and culture.
In their pursuit of cut-rate coding talent, IT managers are choosing to ignore basic rules of structured development, and in doing so, are digging themselves a money pit.
They'd rather try to gain back the dollars undercutting both the potential quality of their project and their local economy than try to adhere to good proven project practice.
Basic methods like those described by Yourdon or DeMarco are pretty darn effective at establishing firm minimum-quality standards and for containing costs.
Those practices have been working for decades for those who follow them with some reasonable level of rigor.
Some in IT have always resisted these methods; opposition has always been present because the structure goes against both of the two basic personality types of the average American programmer who, stereotypically, behaves as if afflicted with Asperger's disorder or attention deficit disorder.
The average programmer doesn't want too much human contact, and doesn't want to lose a shred of freedom to improvise on the fly.
People who manage average programmers get resistance on most attempts to impose structure and tend to either back off or get moved out because the resisters tend to wear down the manager.
Over time, managers who try to impose structure tend to get winnowed.
Structure feels unpleasant to many coders just as marinating themselves in the perceptions of the end user and actual work does. Therefore managers find it easier to yield to the programmers' own ways of working.
So even after repeated under-achievements and even failures of projects that tried to avoid the seemingly unpleasant constraints of structure and end-user input, management falls back on the lazier ad-hoc ADD and Asperger's styles.
The basic guidelines that have been demonstrated to work time after timelike structured analysis and design, self-documenting code, written documentation, usability testing making changes in response to input, running in parallel, et. al.,are almost universally rejected by the very people whose work would benefit from them.
As a result, projects have time overruns and value under-runs.
The combination of the ascendance of finance and the two basic personality types of American programmers make this open sore a persistent drag on development achievement.
In the next column, I'll explain why offshoring has been the response and why it's doomed to underperform in almost every case.
Jeff Angus is a management consultant and has been working with IT since 1974. He has held IT management positions in user interface design, marketing, operations and testing/analysis. Look for his book, "Management by Baseball: A Pocket Reader." Jeff's columns have appeared in The New York Times, The Washington Post, the St. Louis Post-Dispatch and the Baltimore Sun.
Read part 2 of this article to see Why Offshoring Will Always Be a Novelty.