The vicious circle of legacy technology

Photo credit: Jeremy Perkins on Unsplash

Where does a vicious circle start?

I think that, in the case of legacy technology, it starts with an implicit agreement: to optimise for short-term outcomes over sustained capability. I also think that, once that implicit agreement gets the vicious circle of legacy technology going, it gets progressively more difficult to stop.

Let’s take a step back, and make it clear what we mean by legacy technology, and what it means to optimise for short-term outcomes.

‘Legacy’ is a euphemism. In normal language, it means something good: the things that we are proud to leave behind. In enterprise technology, it means something bad: the systems that have truly been left behind, in the sense that technology, capability and best practice have all moved on.

I don’t believe that the term ‘legacy’ is particularly helpful. It enables us to portray these old systems as something that have happened to us, rather than something that we are responsible for. We found these old boxes of code in the attic when we moved in. We don’t know what they do, but they seem kind of important, and every time we try to take them away, the house falls down.

I think it would be more accurate, if uncomfortable, to describe legacy technology as badly managed software and hardware. It is hardware that we have allowed to drift out of date, and it is software that we have allowed to become convoluted and incomprehensible. I don’t mean to blame individual technologists or teams for this bad management: indeed, I think that the teams managing legacy systems deserve more respect than they often get. But there is no use pretending that somebody else inflicted legacy technology on us: we are responsible for its existence.

And that responsibility arises from our willing participation in the legacy vicious circle, where we optimise for short-term outcomes over sustained capability. In more normal language, the circuit around the vicious circle goes something like this:

SPONSOR: I need feature <x> as soon as possible.

DEV TEAM LEAD: Feature x is built, but we haven’t completed the automated pipeline or created all the tests yet.

SPONSOR: I don’t know what any of those things are: if the feature is ready, release it!

DEV TEAM LEAD: I guess that we could do the tests and the release manually, if we put the documentation off until later . . .

SPONSOR: Sounds good, let’s go.

(One year later.)

SPONSOR: Why is feature z late?

DEV TEAM LEAD; We’re still dealing with the fallout of the last production incident. And we still need to schedule the upgrade.

SPONSOR: But we’ve survived without it so far. What are the test team doing?

DEV TEAM LEAD: They’re trying to catch up. But we could move the priorities around again . . .

SPONSOR: Let’s do that. You know, I really appreciate how hard the team works.

It sounds as if the sponsor is the villain of these fragments of dialogue, but it takes two to get the vicious circle of legacy technology turning: someone to demand (normally without a full understanding of what they are asking for) short-term optimisation, and someone to agree (normally without feeling empowered to say no) to compromise sustained capability to provide it.

How do we step off this vicious circle? Better yet, how do we avoid getting on it in the first place? There are three things that might help.

The first step is to recognise that the vicious circle exists. It can be very hard to recognise that reasonable decisions made under pressure are the beginning of a journey into a trap.  But maybe, if we acknowledge that the vicious circle exists, we can ask ourselves, and our sponsors, whether the decisions that we are making seem right, or whether we are about to repeat familiar mistakes.

The second step is to recognise that the sponsor isn’t just expressing their requirements when they ask for feature x to be released now: they are also expressing meta-requirements. They explicitly want feature x; they implicitly want speed and reliability. And we can only deliver speed and reliability from outside the vicious circle: if we make these meta-requirements explicit, we may be able to make a different agreement.

(Note that I am deliberately using the invented term meta-requirements, rather than the more traditional non-functional requirements, to describe attributes such as performance, velocity, reliability and security. I believe that describing something as a non-functional requirement is a great way to avoid people taking it seriously: why would anyone give priority to something that is non-functional?)

The third step is to be courageous and professional. I don’t want to be unfair to myself or all of my fellow technologists, and imply that we have ever not been courageous or professional. But when I look at all the legacy systems I have been a part of building, I have to ask myself whether the perceived pressure from the sponsor was really so implacable, whether we really had to make as many compromises as we did. Did we always explain our choices properly in language which everyone could understand? Did we always present ourselves as professional peers, whose opinion deserved respect?

I try to remember that, however a project is managed, however a system is built, whatever compromises are demanded, the technologists are the builders: it is our hands on the keyboards, and we carry the ultimate responsibility for what we build. If we embody that responsibility, if we make the case for sustained capability, if we join the dance as equals, perhaps we stand a chance of avoiding the legacy vicious circle altogether.