The time to care about code quality is now

What do we talk about when we talk about legacy technology?

Sometimes we talk about infrastructure: hardware that is out of support, operating systems which have not been patched or tools which are out of date. And sometimes we talk about commercial software: packages that have not been updated in years, products which are no longer made, and vendors which have gone out of business.

These forms of legacy can dominate our talk, as they present the most immediate and obvious threats: the unpatched server that is a beacon for attackers, the ancient hardware that may never turn back on again if we lose power, and the support line that just rings and rings.

But often we are talking about software that we have built. We might lament a system that is written in an old coding language which nobody understands any more. We might bewail the unwieldy monolith with so many internal dependencies that we are scared to change or release it. We may regret failing to document the code base which has become a source of mystery and fear. And we may forget that these are problems that we inflicted upon ourselves.

I think that, when we talk about these things, we are really talking about code quality. Anyone who has written code for a living knows that (within limits), it is not the language or its age which stop us from maintaining legacy code: we might not like old languages, but we can learn them. Rather, it is what is said in those languages. Figuring out the syntax for a print statement or the format of an array is trivial compared to trying to make sense of tangled functions and mangled variable names, of coding conventions that change every other line, of kludges and fixes that are there because they just work, even though no-one can explain how. Code can be bad or good regardless of whether the language it is written in was created days or decades ago. (Happy birthday COBOL! 65 years old this month.)

Poor code quality is a drag on digital and business performance. It slows down change, makes systems fragile and freezes functions in place. It is a creeping sludge in the veins of an organisation’s digital metabolism.

But it is rarely a boardroom issue. While organisations and business leaders claim to care about legacy systems - sometimes even enough to fund their remediation - code quality is so far down the stack that they are unlikely even to be aware that it is something they should worry about. Remember that most non-technical people only see the top level interface of a system. Everything behind that is a confusing mystery, and the quality of the language used to build the system is an obscurity too far, especially as a poorly coded system often seems to be just as good as a well coded one - at least for the first release. 

I think that those of us who build and run systems for a living have a job of explanation to do - and that it has just become much more urgent.

First, we should exercise all our skills of influence and persuasion to convince our stakeholders that, not only does code quality matter, but that it is a fundamental indicator of business performance. Code is not merely some arcane wizardry that happens out of sight - it is what their company is made of, and it determines how their company behaves.

Second, we should make the case that, not only does code quality matter, but it continues to matter in the age of AI. Some poor code quality is due to bad practice, insufficiently trained teams, and the scars of serial amendments made over many years. But much of it is due simply to delivery pressure. The last stages of a troubled programme almost seem designed to produce code churn, frantic cutting and pasting and fixing and patching to get something out of the door.

It might seem that the introduction of AI coding assistants will relieve this delivery pressure, raising developer productivity and giving them more time to focus on code quality. This is possible. However, it is also possible - indeed, likely - that the same sponsors who are unaware that the success of their organisation depends on the quality of their code, will expect that AI means that they can go even faster. AI coding assistants are developing rapidly, and we are still figuring out how to use them well - but the signals seem to be that they tend to verbosity, are subject to error and add to their code rather than cleaning it up. That’s true of plenty of human developers too - but that’s why we do code reviews and pair programming. Hundreds of AI assistants churning code in the late stage of a project may give us even more technical debt than hundreds of humans.

AI assistants are another tool in the toolbox, and they will make us more productive. But we must be clear on what type of productivity we want - good quality code that lets us go faster now, and in the future. In an age of acceleration, we owe it to our sponsors and stakeholders to explain why this matters.

(Views in this article are my own.)