The dawn of a post-legacy world
Photo Credit: Sebastien Goldberg on Unsplash
It’s easy to be fatalistic when you work in enterprise technology.
Of course the great big programme will go wrong: great big programmes always go wrong. Of course the infrastructure will fail: infrastructure always fails. And of course we will always have legacy technology: technology becomes legacy the moment it is deployed.
Sometimes this fatalism is cynical: it is the world weary shrug of people who have lived through many failures. Fortunately, though, this fatalism is more often realistic, practical and active, and prompts us to create mechanisms to deal with inevitable failure.
Great big programmes always go wrong: that’s why we break them up into smaller pieces, manage our work through backlogs, and adjust our plans after each iteration.
Infrastructure always fails: that’s why we design reliability and resilience into our solutions, and treat infrastructure failure as an expected operating condition.
Except for legacy.
For some reason, we seem to accept that legacy technology will always be with us, and that it is a debilitating condition to be managed rather than something from which we can be cured.
(Note that, I deliberately use the term ‘legacy’ in the pejorative sense: all those software and hardware components which have drifted out of support, and those code bases which are hard to understand and maintain. I know that life is more complicated than that, and that our attitude towards legacy technology should not be extended to the teams that run it. But for the purposes of this article, we’ll regard legacy as something to regret.)
I do not believe that it does not have to be this way. It is not inevitably true that legacy is always with us. Moreover, I believe that we already know what we need to do: we just have to do it.
The first step is to recognise that we have legacy infrastructure and legacy applications, that these arise from different causes, create different problems, and need different responses. Infrastructure becomes legacy when we don’t manage it effectively: we skip patches and upgrades, and we don’t put mechanisms in place to make those patches and upgrades automatic. Applications become legacy when we don’t give priority to code quality, readability, maintainability and testing.
I don’t even think that we should blame ourselves (too much) for creating both of these forms of legacy. The scale, breadth and complexity of enterprise technology for an organisation of any size can become overwhelming, especially as the demands and expectations of technology grow every day. How can we find time to do patching, when the new system is already six months late, and our sponsors don’t understand the support levels of our infrastructure - and wouldn’t understand if they did? How can we get a business stakeholder to care about code readability when they’re never going to see the code?
As well as creating legacy, though, this overwhelming pressure gives us some indication of how we should tackle it. The complexity is so great, and the pressure is so overwhelming that sporadic, periodic interventions will never work. We cannot ‘remediate’ our way to where we need to be: that is like bailing with a sieve. Instead, we must make profound changes in the way we work.
Firstly, I believe that the best way to manage infrastructure is to stop managing infrastructure - or rather, by getting someone else to do it for you. We are fortunate enough to live in a world which has a growing market in managed service, software defined infrastructure platforms known, of course, as public cloud. It is often said that you don’t fix legacy just by moving to the cloud, but a good move to the cloud, and wholehearted adoption of managed services, fixes a great deal of legacy.
Second, delegating the management of infrastructure creates the bandwidth to focus on what we should be doing: building great software. And building great software does not just mean building software which is functionally rich and innovative: it means building software which is reliable, secure, readable and maintainable. Indeed, those latter things (reliability, security, readability and maintainability) are often more fundamental than the former things (functions and innovation), because you can enhance and innovate on top of high quality software, whereas it is virtually impossible to squeeze quality back into a code base that has gotten away from you.
Technology leaders face the challenge of explaining to their stakeholders why they should spend lots of money on legacy remediation for no discernible benefit. This is a tough conversation, especially if the answer is that we will do no more than make the world incrementally better for a short period of time: we are selling the brief moment when the water in the boat has got a little bit lower, and it has not yet run out of the sieve.
Instead, I think that our answer should be that any investment in addressing legacy is part of the transition to a post-legacy world. We should say that continuous legacy remediation is not a necessary evil: it is an unnecessary evil, and we aim to get rid of it. Our investments will move our infrastructure to a managed service, and give priority to good practice in software development. Not all sponsors will understand these strategies, but they will understand the outcomes: we will never talk about legacy remediation again, your software will do what you need it to do, and your end users will be able to rely on it. Rather than bailing out the boat with a sieve, let’s fix the boat, rev up the engine, and take it where we want to go.
This is, of course, much easier to say than to do. But we build enterprise technology because it holds out the hope of making the world better. A post-legacy world would be even better.
