Not Like That!
How to build the wrong thing on purpose instead of the right thing by accident
by Adam L. Coombes
I really like this book.
It’s divided into seven-minute chapters, which I found particularly effective. They’re short enough that you can get through one whenever you have a few minutes, but there’s enough in each one to give you something to think about. The writing is engaging and amusing too, which makes what could otherwise be quite a dry subject surprisingly easy to read.
At first, I thought the author had misunderstood Agile.
The early chapters seemed to be making the argument that Agile had somehow become a rigid process, and that we had forgotten the importance of actually talking to the people who use the software. My immediate reaction was: wasn’t this what Agile was supposed to solve 25 years ago?
There’s a chapter called Agile Just Made It Faster, and initially I thought this was where we were going to disagree.
But I think I was wrong.
The author isn’t really arguing against Agile. He’s extending and improving the ideas behind it. The point isn’t that Agile is wrong, but that we’ve become too comfortable with the way we practise it. If something doesn’t work, stop doing it and try something else. Involve the user throughout the process. Don’t blindly follow a prescribed approach just because it has an Agile label attached to it.
That resonated with me.
There’s a particularly good discussion around tacit knowledge:
“Tacit Knowledge is the kind you can’t fully articulate. How to ride a bike. How to recognise face. It’s something ‘you just know.’”
This is one of the reasons that trying to specify everything up front is so difficult. There’s knowledge in people’s heads that they simply can’t put into a requirements document, no matter how good the requirements process is.
The solution the book proposes is to build something.
Not the right thing. Not production-ready software. Something approximately right that you can put in front of people quickly so they can tell you what’s wrong and what’s missing.
I particularly liked the emphasis on making this an intentional part of the process. Build a prototype, budget for it, and then throw it away.
In a prototyping session, the notebook is the deliverable and the software is the bait.
That’s a nice way of putting it.
The software exists to provoke a reaction. The reaction gives you information that you couldn't get by sitting in a room writing requirements. And once you've learned what you need to learn, you throw the prototype away and build the real thing.
There’s a lovely line in there too:
“Try not to sell the prototype. Throw it away and build the real thing.”
This is something I think we’re particularly bad at. Once we’ve built something, there’s a natural tendency to want to keep it. And once other people have seen it, there’s an even stronger tendency to turn it into the product, regardless of how it was built or what it was intended for.
The book then moves from reaction to requirement, including some interesting discussions around BDD, user stories and Gherkin. The author clearly likes BDD considerably more than I have historically, but it did make me want to try it again, particularly in the context of AI.
There’s also an important point that AI isn’t particularly good at requirements until you give it enough context. Detailed personas and other context become increasingly important because the model can only work with what you give it.
And this brings the book into what I think is its most interesting territory: AI.
This book feels very relevant now.
There’s a lot of discussion about what happens when the cost of building software collapses. One of the lines that particularly stood out to me was:
“If the cost of building something collapses, the people who used to do the building do not carry on as before with more time for lunch. The shape of the job bends, and it bends first for the developer….”
Exactly.
AI isn’t simply going to make software developers faster while everything else stays the same. If the cost and effort of producing software changes dramatically, the work itself changes. The roles change. The skills that matter change. And the book does a good job of exploring what some of those changes might look like.
I particularly liked the author's suggestions around how we should use AI, rather than treating it simply as a machine for generating code. There’s a recurring theme that the human still needs to understand what is being produced and why.
Which leads to another line I highlighted:
“The model may be responsible, but the human who accepted it is accountable.”
That’s an important distinction.
It also leads neatly into the changing role of the tech lead:
“The tech leads job grows from reviewing human code, to setting the standard for what machine written code must look like and teaching people how to read it critically.”
I think there’s a lot to unpack in that.
If AI is producing more of the code, reviewing every line in the same way we reviewed human-written code may no longer be the most useful thing we can do. The job becomes more about setting standards, establishing what good looks like, and making sure people can critically evaluate what the machines produce.
And then, amongst all this discussion about changing roles, there’s one wonderfully cynical question:
“Is this a real job role, or is it anxiety with a job title?”
I suspect that one is going to age very well.
Overall, I really liked Not Like That!.
I initially thought I was going to disagree with it, particularly around its treatment of Agile, but the more I read, the more I realised that the author was pushing the same ideas further rather than rejecting them. The emphasis on getting something in front of users quickly, learning from their reactions and being prepared to throw away what you've built is particularly compelling.
And the discussion about AI makes the book feel especially timely. Software development is changing quickly, and I think the book does a good job of looking beyond the obvious “AI writes code faster” story and asking what that actually means for software engineers, tech leads and product teams.
It’s short, engaging, funny in places, and has given me quite a lot to think about.
ISBN-13: 978-1066840403
Comments
Post a Comment