Saving America’s software industry
Generally, I don’t have a lot of patience for Alan Cooper. He’s one of software’s more flamboyant personalities, and he often irritates me. I seldom know whether I agree with him or not because he has a penchant for provocative but vague rhetoric. His most recent piece in Visual Studio Magazine is a different story. This is far from the first time he’s made these points, but here he says it better than ever before. The article presents a compelling—dare I say beautiful?—vision of how software should be built, and it contains several interesting industrial-psychological insights, to boot.
Even non-nerds conceivably could enjoy reading it, which is why I’m bothering to mention it here.
The global market continues to offer ever higher-quality technical services at a fraction of the cost of domestic talent. If the software used in this country is going to be Made in the U.S.A. and not mostly imported from the Third World, then we must begin to heal the diseases endemic to software management.
Anybody out there fit Alan’s description of the architect? or the engineer? I’ll be the programmer. All we need is a good business plan and maybe we can give the Indian subcontinent a run for its rupees. 
My diagram of Alan Cooper’s ideas (from an interview he gave last year)
At Microsoft, we have 3 roles—architect, program manager, and software development engineer. PM’s are probably closest to Alan’s “architect”—they concentrate on user requirements. They also write specs, which corresponds more to his “engineer” role, and some PM’s are weighted more to one side than the other. Architects at MS also correspond to the “engineer” role—they tinker to get their ideas into prototypes, but they also fulfill the very important task of designing a cohesive system that holds water technically. Finally, the SDE’s correspond to the “programmer”, but also very much overlap with the “engineer” role—they participate in the design process. Our system seems to work in spite of some of this conflation, and works especially well when the PM’s are customer-oriented.
I think Alan is right about one thing—the customer need trumps everything else. Teams that have very customer-oriented PM’s produce great software. Teams that don’t often take longer to get it right.