A recent conversation and a Cory Doctorow rant have led me to think about how much more complicated our development lives are these days. And how much less fun.
If you’re old enough to remember Waterfall – the software development methodology we did before Agile – then you perhaps couldn’t wait to see the last of it. Waterfall meant slowness, it meant writing a lot of documentation, it meant Big Design Up Front. Documentation had to be reviewed, it had to be signed off. My early days as a software engineer I had to get physical signatures on Design Documents before I could officially go anywhere near the code.
And then there was the code.
It was kept in source control but it was built locally. It was tested locally. It was turned into binaries which we shipped to customers via tape. Our project management was limited to occasional meetings. There were no daily standups. In short, we were trusted.
If it sounds idyllic and relaxed then perhaps in some ways it was. But for a young gun keen to do more I found it frustratingly slow. I wanted to prove that my code was good enough before it was committed. I also didn’t want to have to deal with project managers.
Falling Asleep at the Wheel
The enshittification of software development started with Prince2. A tide of project managers came into our lives and tried to make us more efficient and since then the water has been rising. Agile has become a byword for inefficiency. Tooling has become a lake in which we drown. Open source has become the biggest security headache and the shortest of short cuts to shittier code.
We have gamified the fun out of software development until it is reduced to a series of automated actions and soundbites which are so inconsequential as to make no difference. It is software engineering theatre and plumbing in place of anything vital or exciting.
“Enshittification didn’t happen because today’s companies are run by evil geniuses. They are no more wicked than the everyday mediocrities who founded Sun and DEC and AOL.”
Cory Doctorow
You can accuse me of being simply old and out of touch. That’s fine. I get weird looks from time to time from people who wonder why I get worked up about how we build software and why it matters.
But the how is important because it affects the what. In the same way that Mel Conway said the org affects the architecture. The way we build stuff, the amount of love we feel for it, shows up in the end result.
Similarly there is no conspiracy going on with software engineering. There is no plan to make it as bad as it is right now, it’s just turned out that way because we’ve let it.
Systems of Abuse
Our systems for the most part do not allow us to build software with love anymore. If you’re chasing tickets across a system which allows you only to build incremental Pull Requests which must be arbitrarily signed off by an invisible power structure of asocial senior engineers or architects – what’s in it for you?
Tools created by well meaning entrepreneurs are invested in by VCs and eventually acquired by Microsoft or Atlassian and folded into our work stacks because they enable middle managers to feel better about their day jobs. We drown in administrative tasks which never existed before Agile.
These are systems of abuse. This is the enshittification of our development practice.
Escaping the Walled Garden
Until very recently, I felt that it was possible to navigate these systems and still make sense of our lives as engineers working in corporate-land riddled with these enshittified systems. But I think we need to be bolder.
Systems that force us to add comments, or make us rate our sprints, or enable us to draw dependencies between ranks of meaningless tasks do not add value anywhere.
These are games dreamt up by software engineers, not game designers. We have let mediocre tools take over our lives because we don’t know any better. And companies seem to think that buying Azure Devops or Artifactory or Sonarqube or implementing Public Cloud or Kubernetes means you’re doing DevOps and CI/CD and engineering right. But you’re not. You’re just buying a load of tools and toolkits because that’s what the industry expects. There is a default stack, often imperfectly put together and weaponised to slow down the lives of engineers and their code. What’s worse is that you can only hire people who use the tools and the toolkits which the industry expects.
So we have built walled gardens of enshittified systems. Gardens where you can’t properly explore what it means to create collectively because you are so encumbered and limited by process that creativity is crushed from your soul.
In this life we cannot do great things. We can only do small things with great love.
Mother Theresa of Calcutta
In the battle of head over heart in software development, head won in the last fifteen years. We’ve done too much thinking. But it doesn’t have to be like this.
If you still believe in code, then stop worrying about methodology or process or tool. Aim for simplicity. Dismantle your systems.
Build software with love and purpose and trust.