paralysis in analysis
After graduating about two years ago, I came to know more about the software industry and read about its all time high focus on processes and metrics as a way to ensure code quality. It is understandable, millions and billions of code has been and is being written. The software industry suffers from a miserable failure rate and there are millions of dollars at stake. Scrum seems to be the winner of the agile method wars. It is the Koolkid on the block that everybody wants to adopt. So I was really surprised to find it in a list of the Worst Technologies of the Decade. It makes it easier to know you are not the only one suspicious about this rather bizarre aspect of software development.
I like many of the agile principles. But they are just basic common sense and don’t need a holy textbook or evangelists to support them. Good teams talk to each other. They take unit testing, design documents and code reviews seriously. There are of course strict rules and guidelines governing the ecosystem preventing engineers and teams from doing things their own way. Some evangelists talk about the cross-functional team like it is such a discovery! Isn’t it just natural for designers, artists and engineers working together since the early human civilizations? And really, what’s up with the silly names and unnecessary regimented timetable?
There is a thin line here, too much process can turn the filling dish of a creative job into chartered accountancy with a side of prison. Sometimes it will even demoralize the most passionate geek. Unless it somehow becomes truly agile, it will continue drag everybody down into a mess of meetings and metricsgaming[1]. Too much process makes it very easy to lose common sense and cloud reasoning in the bulk of unimportant details, like paddling hard but getting stuck behind the first wave. Developers can end up spending days generating stories and tasks. They can spend hours on grooming stories before each sprint and hours on tracking time to generate burndown charts for management. If Agile was supposed to be lightweight, then what is this heavy bureaucracy doing in my life? Product backlog, sprint backlog, product burndown chart, sprint burndown chart, daily meeting, retrospective, sprint planning, crap throwing… is this really necessary? It is more likely to spend time on process, and less on actually coding the applications. My colleague once said the ratio is 80% these days. 80% doing errands and 20% actual coding. 20% of their time they spend coding and there is expectation that they will be good and fast software developers?! Without practice? And the team is expected to have a winning software, but without continuous and opportunistic refactoring and incremental design? They would quickly dig themselves a massive hole of technical debt.
The Cult of Courses And Seminars > “To all those belauded sages of the academic chairs, wisdom was sleep without dreams: they knew no higher significance of life. Even at present, to be sure, there are some like this preacher of virtue, and not always so honourable: but their time is past. And not much longer do they stand: there they already lie. Blessed are those drowsy ones: for they shall soon nod to sleep.” (Nietzsche, The Academic Chair of Virtue, Thus Spoke Zarathustra)
Knuth once said: “If I find too many people adapting the same idea, I probably think they are wrong”. Another reason that I have failed to like Scrum is its cult-like approach handing out glossy outlets and diagrams with handwavy math, handed out by armies of evangelists who suffer from too much conviction. Could they pimp their seminars anymore? Even if you love Scrum, you can empathize with me on how ridiculously commercial these things are. Scrum Alliance doesn’t help its religion-like status with its armies of trainers and preachers issuing certificates demonstrating, as James Shore puts it, the connection of someone’s butt to chair during a two days course.
It is indeed like religion. Developers can always blame the creator of the process for not doing it right. And of course there are always developers who think that if anything goes right it will be thanks to the framework, but if anything is wrong it will be their fault. Hmmm, I wonder where I have seen this phenomenon before!
Having said all this, I doesn’t mean that I preach a Cowboy approach. After all, civilization and its discontents is a much better place to live than in a Jungle. But sometimes following listed practices on blind faith won’t work. Standardizing is just so tempting. But there is no solution for all problems. If we cannot adjust to realities and retrospectives, we will be fixing symptoms rather than the disease, creating a big bureaucratic pile of crap similar to the Quebec health system. We must beware of methodologies. All methodologies imply a prescribed approach, a singleminded, fixed set of processes that removes flexibility and rationality. But in software, they’re fundamentally designed for mediocre teams who can’t think for themselves. And I guess that’s great: it’s the key to shortterm success. But working on increasingly complex problems, one might try to at least find a solutions that fits its circumstances with its own domain specific language free from silly terminology.
“Companions, the creator seeks, not corpses, not herds and believers. Fellow creators, the creator seeks those who write new values on new tablets. Companions, the creator seeks, and fellow harvesters; for everything about him is ripe for the harvest. … Fellow creators, Zarathustra seeks, fellow harvesters and fellow celebrants: what are herds and shepherds and corpses to him?” (Friedrich Nietzsche, Zarathustra’s Prologue, Thus Spoke Zarathustra)
In my experience, in a complex scene full of unpredictable actors, when the hype of process catches, when the process becomes the focus rather than people, a Cartesian Scene is created to try and reduce a complex system into manageable separate entities.
“Reductionism is the most natural thing in the world to grasp. It’s simply the belief that “a whole can be understood completely if you understand its parts, and the nature of their ‘sum’”. No one in her left brain could reject reductionism.” (Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid)
However, this method is mute in explaining the complex phenomena closest to our human-scale concerns. Maybe instead of going back to Descarte, we can look for Spinoza. Sometimes entities are continues substances, never separable. Is it really as easy as the consultant says? I remember one of my teachers said that 80% of projects fail now. Many are using Scrum. In the past also, 80% of projects were failing. He said maybe what it really means that only 20% of software teams are really competent. The only truth in this field is that is that great programmers write great code. But only passionate programmers have the chance to become a good programmer one day, and this only happens by hard practice; writing and making mistakes in presence of great programmers.
References 1. Process kills developer passion O’Reilly Radar. 2013. Process kills developer passion O’Reilly Radar. [ONLINE] Available at:http://radar.oreilly.com/2011/05/processkillsdeveloperpassion.html. [Accessed 11 July 2013].