Impact Engineering: a review
Read it, probably. Do it, maybe.
I feel like a lone and looney voice sometimes, howling in the wilderness. Particularly so when I critique the cult of Agile-Scrum, and when I propose a more context-aware style of development. So, I was encouraged recently, to hear two of my niche opinions echoing back at me.
One such echo was some noise around Observability Driven Development (I’ll blog about that soon).
The other was Junade Ali’s Impact Engineering.
This article on The Register first alerted me to Dr. Ali’s new book. The article highlights his claim that Agile projects have a 268% higher failure rate than non-Agile ones. (Oh, how I chortled.) Of course I bought the book, and read it in one sitting — it’s not long.
My verdict? Mixed feelings.
I’m in tight agreement with Ali’s main thesis, I just wish he’d been more careful in proving it. I’d give the book about a 7/10 for core ideas, but only 4/10 for presentation.
The author has strong insights, backed by his extensive research and by his personal experience. The book includes: analysis of what predicts a project’s success or failure; a study of the things that matter most to customers and users; and a sketch of his new, ‘better-than-Agile’ workflow.
He highlights powerful results from academic psychology, which, while familiar to wider business culture, are too rarely considered as a factor of software team performance. It’s commendable that he takes the risk of facing into emotions and personality styles — and disclosing personal challenges that he’s overcome. As an industry, we’re too prone to confining engineering and engineering management within their drily rational stereotypes, while disregarding useful info about human motivation and human interactions. (Software can‘t be any more functional than the meatware producing it, after all.)
I like his topic; I like his emphases; I like some of his conclusions.
Some other conclusions go far beyond what’s justified by the data. I’d like to address that. But first, a few small gripes about style.
Why pay for solid research, consulting thousands of software practitioners and customers, to then present its results as a business novella? This choice of genre makes the text awkward to read. I was irritated by the constant digressions, describing in dull detail how Ali’s semi-fictional characters (he admits they are ciphers of himself and former colleagues) drank their rums and coke, ate their chips, collected their air miles, and peeled their potatoes. The first 80% of the book proceeds in this fashion, with characters dialoguing back and forth on disparate topics, like system design, hunger hormones, and delayed gratification. I waded on through it, expecting that these many strands of thematic spaghetti would eventually congeal to a synthesis, to justify his Impact Engineering method as technically and sociologically optimal.
No synthesis emerges. In its penultimate chapter, the book flips abruptly away from the fictional backstory (‘an ailing tech project is saved by writing the functional specification’) to directly and factually present the real-world data gathered by Ali’s research. The final chapter is just a two-page summary of Impact Engineering’s values.
I think he’s implying, with all his talk of ghrelin and leptin and the Stanford Marshmallow Experiment, that doing full System Analysis and Design in advance of writing code is equivalent to the healthy behaviours of those who can delay gratification, and that Agile is a dysfunctional practice that favours tiny, early sub-deliveries over satisfactorily working apps. All true — but it can be stated in one sentence, without writing a novel. Likewise, the book’s rambling discussion of cognitive biases and Loss Aversion hints obliquely at why people are reluctant to drop the familiar Agile method: it might as well have been stated explicitly, and briefly.
The author has a few, really good, simple points to make — so blindingly obvious to anyone not brainwashed by Agile that they hardly bear stating. I believe he may have chosen his format in an attempt lure in Agile-ists, and gradually soften them up to his point of view. Maybe it will work on someone. For me, it was just a lot of good content, mashed together in a stream of non sequiturs.
So what about Impact Engineering as a methodology? Well, OK, yes, the basic suggestion is sound: discover your customer’s problem in detail; then design a complete solution; and only think of building anything once the solution is clear. Its approach to implementation and testing makes less sense. Ali is very keen on using Lean, with stringent WIP limits, even though his own study of a couple-of-thousand projects finds no evidence at all that WIP limits favour success. (In fact, he found a very slight negative correlation between Lean and successful outcomes.) There’s no reason, not from his research findings nor from the anecdotal evidence in the ‘novel’, that Scrum wouldn’t work just as well as Lean, as long as you write the spec in advance of the sprints.
I’m actually a little embarrassed to be so critical. This is a book that asks all the right questions. It’s a book that provides very sensible answers. It is timely and topical. It provides some very useful and informative statistics, which complement other research in the field, like DORA. It uses a narrative style that may make its content more relatable for non-engineers. It’s honest and humane (preciously rare qualities in its genre).
Its big flaw is just over- labouring what is ultimately a very simple point: that the Agile emperor has no clothes, because … now say it with me, ten times fast …
The Best methods for Software Engineering are Engineering Methods.
The Best methods for Software Engineering are Engineering Methods.
The Best methods for Software Engineering are Engineering Methods.
The Best methods for Software Engineering are Engineering Methods.
The Best methods for Software Engineering are Engineering Methods.
The Best methods for Software Engineering are Engineering Methods.
The Best methods for Software Engineering are Engineering Methods.
The Best methods for Software Engineering are Engineering Methods.
The Best methods for Software Engineering are Engineering Methods.
The Best methods for Software Engineering are Engineering Methods.
