When any critical eye sweeps over the software development landscape, even a cursory look reveals dysfunction, misunderstanding, failure, incompetence, and distrust.

It’s no one person or one group’s fault. Those managers closest to the problem, like agile coaxers and scrum lords, refuse to see, or even acknowledge the pain and suffering in the development community. Most middle- and project-management rackets depends on an echo-chamber of self-congratulations and an overarching appeal to authority (theirs). Any dissonance or rejection of their authority disrupts their control and position. Pain, we’re told, signals a severe problem. To the middle- and project-manager, there can be no problem. They’re certified.

Unfortunately, parlor tricks and certifications elevates no one to authority when twenty years’ of deferring to the “authority” hasn’t rendered the comprehensive improvements each iteration of the managerial or fr(agile)/scrum racket promised.

Most middle- and project-management rackets depends on an echo-chamber of self-congratulations and an overarching appeal to authority (theirs).

Successes occur under certain more successful fr(agile)/scrum lords with the same frequency as in history without them. About seventy percent of projects either fail utterly, or go over budget and beyond schedule. About 20 percent get cancelled completely. Most software products go to market with significant and known flaws just to hit the time and cost targets.

Worse yet, software developers – the highly skilled experts in the middle of the maelstrom – bear the majority of the pain in failure, and carry the blame, almost fully. Even when the software developers wield no authority, carry no veto, and cannot even reject plans because they know them to be poorly-considered and mostly political; they end up with all fingers pointing at them.

The decision makers persist, though, with a foolhardy pursuit for better process, better management, and more control because this is what managers understand.

Neither management frameworks nor process toolkits have improved the state of software development in the last decade and a half. The decision makers persist, though, with a foolhardy pursuit for better process, better management, and more control because this is what managers understand. Managers do not understand software development and, therefore, cannot parse and analyze the systems and problems. Technology is the blind-spot of management.

We trifle with the forces of nature when we choose blindness combined with the kind of aggressive dedication only ignorant managers seem capable of mustering. Nature never forgives. God may; but nature never does.

They live inside a sterile bubble of uniform opinion, often leaning on endorsements from similar middle management with identical backgrounds and familiar ideas.

Software development projects rewind and replay the famous black-and-white film footage of two old steam locomotives on the same track, heading toward each other at their top speed. When they meet where everyone expected them to meet, the destruction is glorious! Loop. Repeat. Bang!

But it’s not so glorious when I’m riding one of the locomotives – or worse yet, if I AM one of the locomotives.

Despite contrary claims, middle managers – including fr(agile) coaxes and scrum lords – publicly reward opinions that tickle their ears and routinely penalize anyone critical of their efforts. They live inside a sterile bubble of uniform opinion, often leaning on endorsements from similar middle management with identical backgrounds and familiar ideas. While they seek their greatest level of comfort, they allow a constant assault on the very thing they purport to defend: the software developer.

Next: Something’s Wrong With Management