Slow software development

Originally published on my blog.

I've been trying to write this piece for a while. For some reason I'd decided that it needed a lot of research or careful consideration, but it really doesn't. I don't need to have tons of sources. If I think of some I can always come and add them later - that's the beauty of the dynamic web.

The slowness movement

Maybe 8 years ago I stumbled upon the concept of "slow news" (slow media, slow journalism). This is a reaction against the habit in the media of rushing to cover the latest story, resulting in reporting that only ever has time to be skin deep and will often miss more thoughtful takes and ultimately fundamentally miss the truth. Instead, we should take time to cover a story, going deep with analysis and perspectives, carefully uncovering many hidden layers, for a far richer understanding.

This is just one example of a broader slowness movement, which seeks to generally push back against the pressure to always go faster and instead take the appropriate amount of time to solve any problem.

The point is not to go as slowly as possible, but instead to go at the appropriate speed. In our modern consumer-driven world, this almost always means going slower.

There's a TED talk about this, which I haven't actually watched, but intend to when I get a chance.

To my mind, this also relates pretty deeply to ideas like sustainable development, prosperity without growth, donut economics and ultimately even net zero. So it's super relevant to our time.

I can see that in many ways "sustainable" is the more descriptive and palatable way to describe what slowness is trying to represent - it sounds far less jarring. We could also use words like "considered". But for that exact reason I prefer the term "slow". It makes it clear that there's an uncomfortable change that needs to be grappled with - this isn't just business as usual.

So what about software?

Applying the idea of slowness to software development feels particularly jarring and apocryphal, because performance culture is so deeply embedded in the industry's psyche.

I've been reading "A philosophy of software design" and I really like it. One thing I think it represents is an explicit push against Facebook's "move fast and break things" culture.

Agile will tell us to add an item to our backlog in a fairly minimal form, pull it into a sprint and then rush to get it out the door within two weeks. In APOSD, John urges us to take the time to push back against hasty design decisions. He argues that emphasising "tactical" quick fixes will add to the complexity of the code, adding technical debt, so fast that even startups will be crippled by complexity before even reaching an initial release. Instead we should take the time to be strategic in writing our code, carefully designing interfaces, separating concerns, building deep modules.

Considered design

If I think about the developments in tech that have really impressed me, that have led to sustained value, they're all carefully considered. They're certainly not Facebook. They're Docker, HTML5, GDS design principles, LetsEncrypt, USBC, the iPhone, Dyson products. They're not rushed out, their design is carefully considered.

This is the way to solve problems well, in a lasting way. It's also the way to feel proud of your work.