|Perl: the Markov chain saw|
Thought I should round up my answer more even-handedly.
In practice, I feel managers and programmers (or any "technical" personnel) are as much a victim as vilain, since most of them were never taught how to work with each other.
The CS curriculum normally focuses on programming, nothing much on how to work with people. (Like, a programmer might always complain a req spec wasn't "perfect," instead of helping a non-techie how to write a spec.)
A biz program teaches quite a bit of concepts and theories, but not every biz student came out with good implemenation knowledge (theoretical or pragmatic). I usually found them lack of any concept of "stable system" and why you can't meaningful fix and improve a system that's not "stable." Instead, management by crisis or mgt by (annoying) cheerleading is a common style, which often amounts to destablizing a system.
It would be better if mgrs and programmers have overlapping knowledge that helps bridge their communication gap. In an ideal world, we could have the following:
Stylized view of the distribution of knowledge and skill sets
1.sys analyst -- system-wide architectural issues
lead programmer -- individual applications
If people don't come in readily with what it takes, we just have to train them in house (if feasible).
See that, on one hand, the major reasons of the software projects' failure (as a business) are "managerial," rather than "technical;" on the other hand, managerial decision process is a collective effort, not just by titled managers.
In reply to Re: Re: Re: XSL/XML/Perl as a development process