The three flavours of legacy: sour, bitter and sweet

What does legacy technology taste like?

That might seem like an odd question, not just because it’s strange to ask about the taste of technology, but also because it might seem obvious that legacy tastes bad. We usually talk as if legacy systems are unequivocally awful. We have legacy remediation programmes, legacy reduction programmes, and legacy elimination programmes. We sometimes seem to put more effort into getting rid of legacy systems than we do in building them in the first place.

However, I think that the world is not that simple, and that it’s more helpful to think of legacy systems as coming in three flavours: sour, bitter and sweet.

Sour Legacy

Legacy is sour when it has gone off over time.

This does not have to be the case. Despite our talk about ageing technology, and horror at the idea of systems that were built twenty or even thirty years ago, old does not necessarily mean bad in the world of technology. Well-written software will keep on doing its job, as long as that job stays the same and it has a stable environment to run in.

Why, then, does it feel as if systems go bad? Why does the cost and risk of legacy systems seem to increase with age? Why do legacy systems seem to sour like milk?

The answer is that, at the infrastructure layer, software does something that looks very much like going bad. Systems software is extremely complex, all complex software contains bugs, bugs create vulnerabilities, and vulnerabilities attract attackers.

Exposing systems software to public networks is like opening a bottle of milk to the air: it begins an inevitable and inexorable reaction. It does not create vulnerabilities: those were always there. But it creates an environment in which they will be discovered and exploited. And the discovery of vulnerabilities is a function of time.

Unfortunately, the answer is not to avoid exposing systems software to public networks or to potential attackers. This exposure is inevitable: you and your organisation may choose to keep your systems software secret and hidden, but the rest of the world has access to the same software with the same vulnerabilities. It is as if one person opening one bottle of milk opens all the bottles of milk in the world.

The only remedy to stop our legacy systems going sour at the infrastructure level is continuous refresh. This is where the food and flavour analogy seems to break down: I don’t think that we would feel comfortable drinking a bottle of milk if we were assured that some of the milk was replaced every day.

But maybe getting a new bottle of milk every day is more like ephemeral infrastructure. At this stage of our ongoing battle with legacy infrastructure, we should have learnt that the best way of keeping things current, at least for systems software, is not to patch it, but to destroy it and replace it with an up to date version. And, while this may not fix things at the hardware layer, it helps us abstract the hardware refresh cycle from the software refresh cycle.

Of course, time does not only drive the detection and exploitation of vulnerabilities; it also drives the support status of the products that we use. But the taste - and the remedy - are the same.

We can avoid sourness by keeping things fresh.

Bitter Legacy

Legacy is bitter when it carries the consequences of choices we regret.

Once again, old does not mean bad, and working software will not only go on working indefinitely, but will also always be infinitely malleable. All we have to do is change it.

Why then, are older systems so hard to change? Why are our change plans always bottlenecked at the same systems? Why do we have that bitter taste when our programme depends on changing legacy?

The answer is, of course, that, in most cases, in most organisations, the readability, flexibility and maintainability of code is not given the same priority as immediate functional capability. Often when organisations talk about technical debt, they are referring to product choices that went against their standards, about macro compromises in their architecture. But the most damaging technical debt is that which accumulates in the code: it is the result of thousands of decisions made under time pressure, without the opportunity to go back and fix things.

That is why this form of legacy tastes bitter. Sour legacy, where infrastructure drifts out of date and becomes vulnerable or unsupported, is a function of the nature of commercial products and the people who want to attack those products. Bitter legacy is a function of our choices.

The only remedy to legacy systems becoming bitter at the application layer is to give priority to readability and maintainability throughout the entire product lifecycle - and to create time to refactor the consequences of the regrettable decisions we will inevitably make. It is a matter of paying off our technical debt early and often, before the interest becomes overwhelming.

This is, of course, easier to say than to do, but the alternative is endless years of legacy remediation - a bitter prospect indeed.

We can avoid bitterness if we care about code quality and act accordingly.

Sweet Legacy

Legacy is sweet when we have well-maintained, well-run functional code which we understand well and which continues to do its job. It is the proof that old does not have to equal bad, and it lives up to the normal meaning of the term ‘legacy’ in the language: something of value passed between generations.

It might seem hard to believe that sweet legacy exists, especially if you work in a large organisation. But it is all around us. Look at old Open Source projects. Linux was released in 1994, and it is everywhere today. We might argue that the original code has been fully replaced over time (I must admit that I haven’t taken the trouble to check the repositories), but that’s what sweet legacy means: technology which stands the test of time, even when (or because) it has been completely changed, piece by piece, like the ship of Theseus.

To recap: sour legacy is when technology goes bad at the infrastructure layer, increasing the risk of failure or compromise, and is best addressed through continuous refresh and ephemeral, software-defined infrastructure; bitter legacy is when we degrade the quality of software at the application layer, increasing the cost and effort of change, and is best addressed by paying attention to code quality and creating time for refactoring; and sweet legacy is when we build things well and look after them, creating robust, secure, flexible solutions which stand the test of time.

What does your legacy taste like?

(Views in this article are my own.)