Many software projects fail, or in various ways don’t achieve the expected results. This is widely known. Loads of people offer cures, for example the fact that the critic’s favorite software development method wasn’t used, or it if was used, wasn’t used correctly. Training! Consultants! More SCRUM masters! Not just stand-up meetings, but stand-on-your-tippy-toes meetings!
There is a fatal flaw that often causes software projects to turn out badly. It’s rarely discussed. It’s sometimes called motivation, but it comes down to whether the people doing the actual work – you know, writing the lines of code – feel ownership in what they’re doing. If they don’t own the work, their eyes will be glazed over, and the most productive corners of their minds will be engaged elsewhere.
If they’re engaged, excited and feel they own the project, however, they are likely to be chastised, boxed, referred to HR, etc. Someone will sit down with them and utter phrases containing words like “team,” “supportive,” “respect other people,” and so on, all of which are generically good, I guess, but amount to something like this: “Sit down, shut down, keep your nasty opinions to yourself, stop putting other people down, and just do your work.” In other words, go through the motions.
The people who say things like this are mostly not programmers – they wouldn’t know a line of code if they tripped on it – or are sometimes go-along type programmers who see that corralling wild programmers is the path to higher pay and increasing management responsibilities – in other words, more pay for less work.
Dilbert has an on-point description of software management.
Yes, some good programmers are mean, sometimes. But mostly they just sound mean when what’s really going on is that they’re reacting strongly to stupid ideas or proposals. Because they care. The targets of their wrath should grow up and consider the possibility that they’re doing the equivalent of proposing that the race should be run by people holding their hands behind their back, or hopping on one foot. Is it nice to mock such a brain-dead idea? No. Should the person proposing the brain-dead idea be made to understand that they’d better do a brain transplant and get a brain that’s at least moderately alive, or switch jobs to serving the coffee? Yes. The sooner the better. Perhaps the idiot could even try listening to the “mean programmer” and understand the substance of what they’re saying, instead of just the emotional baggage.
That’s a nice fantasy, but very rarely happens. Most often, it’s the unrestrained programmer who is put down. Top programmers are given a clear choice. Choice 1: leave. Choice 2: do what you’re told and stop caring.
Dilbert boils it down: learn to lie.
Dedicated MBA/HR types will counter with stuff about the importance of teamwork, how the team succeeds together or fails together, the programs they run to inspire motivation, belonging and dedication to quality, and all sorts of good-sounding things. Good intentions! Sorry, but in the end, the only thing that matters is results. If your “team” has carefully included everyone and reached a consensus about the best path to get to the top of the mountain, and gets stuck part way up with nowhere to go except jumping a cliff or retreating to the base of the mountain, well they’ve failed together. I hope they’re happy. Meanwhile, some collection of misfits could be charging up the mountain in leaps and bounds, anticipating obstacles that your wonderful crowd of conformists and liars were blind to, and reacting creatively to obstacles they had failed to foresee, overcoming them quickly
This is one of the big reasons why large organizations can’t get software done: they are infected with large numbers of trained, credentialed managers and HR people who know nothing about the substance of software and are convinced that their generic management methods should reign supreme.
Comments