A cult of well-meaning but delusional academics has hijacked the consciousness of a lot of our peers. The cult is busy leading IT groups into absurdly dysfunctional behaviors that suck the life out of projects and that will take down entire midsize organizations competitiveness.
Their vision is built on two blind spots and two personality abnormalities that enable them to miss a pair of truths that couldnt 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 cant 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 price—the 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.
Theyd 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 Aspergers disorder or attention deficit disorder.
The average programmer doesnt want too much human contact, and doesnt want to lose a shred of freedom to improvise on the fly.