The whole concept of “software engineering” or systematising the effort of writing computer software has taken a very strange turn of late. There are some cool tools around for building software systems and proving quality, not least automation in which AI of course plays a huge part, but all of this is offset by the sheer amount of fluff, management and framework nonsense, planning and incessant talking that has crept in and grown louder.
Fuelled and scripted by AI, middle managers everywhere suddenly appear to be experts on the Software Development Lifecycle. I mean, a few years ago you couldn’t say “Software Development Lifecycle” in a meeting without everyone crossing their eyes and thinking you’ve lost your last marbles. Now all the buzzwords have been mixed effortlessly together using a sprinkling of the magic fairy dust of AI, and bingo, we all have to suffer through hours of presentations telling us how agentic software development is here to stay.
Not only that, they tell you that you must write down everything you do in order to share a common language with the agents. I mean, if “they” are so smart then why can’t they just deduce it, huh?
But the biggest elephant in the room is the assumption underneath all of this:
That we can specify software.
I’m sorry to be a party pooper, but humans are very bad at telling you what they actually want.
Software makes this problem considerably worse.
You cannot fully specify most non-trivial software before you start building it, because building the thing changes your understanding of the thing you’re trying to build.
How can I say this with such certainty?
Well, it’s been tried before.
Repeatedly.
I asked ChatGPT how many times the software industry has attempted to solve this problem by pushing more and more of the uncertainty upstream into specifications, models, processes and tooling.
So how many times?
If we’re counting distinct major industry waves, it’s something like 8–10 and that’s just a conservative estimate.
| Era | New name for essentially the same dream |
|---|---|
| 1960s | Software engineering / systematic development |
| 1960s–70s | Software factories |
| 1970s | Formal specification |
| 1970s–80s | Automatic programming |
| 1980s–90s | CASE / structured methods |
| 1990s–2000s | UML / model-driven development |
| 2000s | Agile’s “opposite” reaction |
| 2010s | Infrastructure as code / declarative systems |
| 2010s–20s | Low-code / no-code |
| 2020s | AI-generated software |
Different technologies. Different terminology. Different generations of consultants and companies selling the same old stories and yes, I was there among it all, thinking this sounds too good to be true.
The recurring idea:
If only we could describe what we want precisely enough, building the software would become largely mechanical.
At the NATO Software Engineering Conference in 1968, one of the arguments being made was essentially that you can’t simply specify the thing first and then build it, because you don’t fully understand the thing until you’ve tried to build it.
Nearly sixty years later, we’re still having the same argument.
Perhaps AI will finally solve it.
Perhaps this time will be different.
Or perhaps we’ve once again become fascinated by the idea that the difficult part of software development is writing the code.
It isn’t.
The difficult part is figuring out what the hell we’re actually trying to build, discovering that we were wrong, learning what we actually need, and then changing it without breaking everything else.
So, Mr, Mrs or Ms Enterprise Architect:
Build your frameworks. Define your processes. Create your taxonomies. Write your agent instructions.
But please stop pretending that you’ve discovered a way around the fundamental uncertainty of software development.
And please, for the love of God, stop denigrating the people who have spent decades actually doing the work.
It’s still a noble profession.
It would be nice if we remembered that.