Software development and the problem of akrasia

Photo Credit: Elisabeth Lies via Unsplash

Why do we have the extra slice of cake? Why do we skip the session at the gym? Why do we watch another episode of the TV programme when we know we should be studying?

In philosophy, these are problems of akrasia, or weakness of the will. Put simply, the puzzle is: if we know that we should do something (or not do something), and we want to do that thing (or not do it), how is it possible that we put it off (or choose to do it)? Why do we do the things that are bad for us, even when we know that we are bad for us?

This might seem to be one of those questions that only a philosopher could worry about. Isn’t it obvious? We eat the extra slice of cake because we like cake, and, in the moment, our pleasure matters more than our long term health. We skip the session at the gym because it seems too much like hard work, especially compared to extra time in bed or another cup of coffee. And we watch more TV instead of studying because we’re caught up in the programme - and there’s always tomorrow.

But, like many philosophical questions, the problem of akrasia seems more relevant the more we think about it. Who is really in charge here? What happens when we listen to our better instincts and do the thing that is good for us? How did we make that happen? How can we make it happen more frequently?

I don’t pretend to know the answer to the general problem of akrasia, but I do believe that we see it frequently in the world of enterprise technology - and that in that specific context, we may be able to come up with some answers.

I believe that one of the most frustrating aspects of enterprise technology is that we have known good ways to organise the work of building and running computer systems for many years. These ways attract different labels, such as Agile, DevOps and Product Management. Sometimes we invent new labels (such as Platform Engineering or Site Reliability Engineering), and sometimes these new concepts and categories of concepts can be confusing. But I think they can be reduced to a relatively small number of truths: software is best delivered by small, persistent teams of empowered experts who have the time and space to care about the quality of what they produce and its performance in production, who manage their work dynamically, and who apply their own tools - software and data - to their own professional practices. (We could now argue for several years about whether this simple description is correct, but I hope it captures the essence of what we are about.)

And yet, despite knowing these truths, most development and management of software is not organised this way. Large enterprises still run giant, monolithic programmes, founded on the belief that it is possible to build a precise plan for software development that stretches over months and years. These programmes are still treated as complete endeavours which deliver finished products which only require minimal maintenance after they have gone live. Organisations still go through lengthy requirements gathering exercises in the belief that it is possible to specify the desired behaviour of a software system before a line of code has been written. Developers are not trusted and treated as valuable, but as coding machines who ‘just’ need to turn the requirements into software. We do all these things, despite knowing that they are bad for everybody involved.

Fortunately, it is relatively straightforward to diagnose this form of akrasia, even though it is much more difficult to fix it. In most cases, this type of digital akrasia is born out of a combination of ignorance and intuition. Ignorance because, although we have been building software systems for decades, most people who sponsor the development of such systems have never had direct experience of building software. Intuition, because most such people do have direct experience of other things we build - such as roads, bridges and buildings (even if only as a driver, user or occupant). It is not unreasonable, if we are asked how we should organise the work to build something that is complex and expensive, to suppose that we should organise it like a construction project.

I’ve written for the last few weeks about interesting engineering problems. Many of those problems are technical, but some of the most interesting are behavioural. One of the things that the Chief Engineer will need to do - that all technology leaders need to do - is educate and advocate for doing things in ways that we know to be successful, and explaining why building software is not like building a bridge.

This is difficult. It needs patience, the ability to communicate, and the investment of time to build trust. It also needs courage, a willingness to challenge, and the persistence to sustain belief when things go wrong. These can be tough days in the office. But if we don’t do these things, then we succumb to our own type of akrasia.