I like spaghetti on my plate, not in my code

If you have ever attempted to update or maintain code, you know what spaghetti looks like. Even more, you know what it feels like. You are familiar with that sinking feeling when you realise that, in order to make a change that should be simple, you need to go deeper . . . and deeper . . . and deeper. You know what it means to build a mental map of convoluted code, to put virtual fingers and pins in place to keep track of important pieces of logic - and then for that whole map to vanish when you get distracted or interrupted. You know what it’s like to make a change without full confidence that you understand what you’re doing, and hope that the tests will save you from the most damaging mistakes - only to realise that the tests are even more cryptic than the rest of the code.

Like many things in enterprise technology, though, it’s hard to explain what spaghetti feels like to non-technical people, to make clear the impact it has on reliability, on agility, and on the ability of teams to feel good about their code base.

There is an increasing number of introductory coding courses for non-technical people. This is a very welcome development: all people working in business should have the chance to learn at least some code. Some of them may even learn to like it. But, by necessity, these courses tend to be quite short and simple: they often teach students how to build a simple web app not far beyond ‘Hello World’ complexity. This is just enough to help people appreciate the power and potential of coding, and understand what their technical teams do. But it is not enough to convey the reality of building complex systems from scratch, let alone the reality of maintaining code which has grown organically over years and decades.

Maybe there is a market opportunity here: an escape room experience which conveys the feeling of making a small change to a legacy code base. Except that you would probably need an escape building, with rooms nested within rooms, elevators that suddenly dump you at the entrance, and empty corridors no-one has been down for years. I’ll leave that idea for someone else to develop. (Although if you happen to be in San Jose and you want to give your business stakeholders just a taste of what a legacy code base would look like in real life, you could do worse than take a trip to the Winchester Mystery House: it could provide more insight on your Silicon Valley study tour than visits to a dozen start-ups.)

As is usually the case, this gap in understanding leads enterprises to behaviour with unintended consequences. We build a system, against the clock and with many compromises. We prove that it meets outward needs (performance, reliability, functional behaviour) but rarely test that it meets inward needs (readability, maintainability, agility). We run many projects or other initiatives over the years, driven by similar priorities, and the system gets steadily more functionally rich - and steadily more incomprehensible. It spaghettifies: a term usually used to describe what happens when an object gets too close to a black hole, but one we’ll use here to describe what happens to code when it spends too long in the company of normal enterprise code management practices.

And then, after much dis-satisfaction, after many failed projects and missed deadlines, we come to realise that this legacy system is beyond saving. It is just too hard to maintain: we need to decompose, to refactor, to replace: whichever tactic we use to describe throwing it away and starting again. We have the chance for clean code. Except . . . have we changed our ways? Are we going to give priority to readability and maintainability? Are we going to make time for peer review? Are we going to measure code quality as much as - or more than - we measure functional capability? Because if we’re not going to do any of those things, then we’re just creating the next generation of spaghetti. I like spaghetti carbonara and spaghetti vongole, but they’re both still spaghetti.

The spaghettification of code may seem inevitable, like the increase in entropy prescribed by the second law of thermodynamics. Yet, like entropy, spaghettification can be reversed - even if only locally and with a good deal of energy. That energy must come in the form of good coding practices, of a belief that code is a valuable asset that we must care for, of a faith in the possibility of professionalism. It must also, as ever in the world of enterprise technology, come in the form of tireless explanation, and of making the case for not just replacing today’s spaghetti, but replacing it in a sustainable way that resists spaghettification.

The core lesson here (and one that I have learnt painfully over the years) is that while it may make sense to replace legacy systems that are beyond repair, if we do not also replace the practices that put them beyond repair, we will find ourselves in the same situation again. When we make the case for change, we must not just make the case for changing our code, but for changing the way we think about, value, manage and care for code. Otherwise we are just swapping one spaghetti dish for another.

(Views in this article are my own.)