Today's entry in Scott Berkun's blog (Asshole driven development ) is brilliantly scathing. The comments are also handy for identifying the key dysfunctionality in an organization.
A couple of years ago Mark Grand shared with me a number of things that seem to make software development needlessly clumsy and complex. Indeed, he theorized that there is a culture of complexity that worships clumsy process and management inefficiencies.
There happened to be seven kinds of dumb-ass complexities. It isn't like the standard deadly sins actually match up with complexities; the seven is just coincidental.
Cause and Effect
The net effect of failing to come to grips with complexity are the dysfunctionalities that Scott Berkun (and many others) identified in his blog entry. Let's look at a few.
ADD (Asshole-Driven Development) for example, tackles everything head-on. If you have a conflict between end-user requirements and technology budgeting, then an chief asshole can make a certain kind of motion happen: it may not be progress, but it will be activity.
CDD (Cognitive Dissonance Driven Development) is a way of encouraging a quantity of ideas in lieu of any high quality ideas.
CYAE (Cover Your Ass Engineering) is what you do when you have a fragile, immature process. Rather than actually solve the problem, you layer in more complexity -- particularly complex processes -- because that's rewarded more than success. There's nothing like an integration test, performance test, QA test, user acceptance test, regression test dance to replace real understanding of the user's requirements.
DBD (Development By Denial) is a way to cope with a failure to assess risks. Software development is always about management of ignorance: you must be ignorant of something, or you'd just download the solution. Either you don't have the use cases fully understood, or the technology is new, or both; that's why you're building something. Failure to manage ignorance means you are doing DBD development.
"In the real world we don't have time to explore every nuance," for example, is classic DBD-speak. Somehow ignorance must vanish, but we can't spend money on exploratory proof-of-concept prototypes or training in the new tools.
GMPM (Get Me Promoted Methodology) is what we do when we have a deep-seated fear of showing weakness. We lead by fiat, making sure that our decisiveness gets us noted and promoted.
Conclusion
When you don't know what you're doing, you pick a leadership style that maximizes activity in the hope that it might maximize progress. You can be a jerk, foster disagreement, cover your ass, deny the obvious, and leverage the situation to make yourself look good.
I think Mark was right, the complexity of software, and software development, makes people into bad leaders.
I think complexity and bad management are behind IT's Drive To Self-Destruction . My person gripe centers on Next Year's Dollars (NYD) being less valuable than this year's dollars. Dumb, bad design can be forced into production because maintenance (which goes on for decades) is cheaper that getting something done by the fantasy dead-line date.