I was going to do something about legacy technology but I forgot . . .
Photo credit: Dianna Clifford via Unsplash
Have you ever had the weird experience of reading a book and, part way through, realising that you’ve read it before?
Or being recommended a book, going to buy it, and realise that it’s already on your e-reader, marked as read?
Human memory is strange and fallible. It seems that it is possible for us to spend hours engrossed in an activity which occupies our minds, and then completely forget about it.
This experience may not be surprising to people who have the hard job of maintaining legacy systems. If you’ve been working for a system for a while – possibly years – it is not uncommon to come across a tangled mass of code and ask, ‘What idiot wrote this?’ only to realise that it was you.
Corporate memory is even more strange and fallible than human memory. It seems that it is possible for organisations to spend years and millions building systems, only to forget how they work on the day they go live – and then to ensure that all memory is thoroughly buried by disbanding the project team, ramping down investment and failing to maintain documentation.
Unlike the fallibility of human memory, though, this form of corporate amnesia is a choice. True, it is not always a conscious choice – plenty of organisations still don’t understand the difference between building a bridge and building software, and mistake the end of the project for the end of the work. But it is, nevertheless, a choice.
And it is a choice with consequences. There is more than one source of legacy technology. Sometimes it comes from other people’s products, which either they or we (or both) fail to maintain and upgrade. But the legacy which comes from corporate amnesia is more pernicious – and we are more culpable. This type of legacy gets harder and harder to remediate over time, as the code gets more and more obscure and impenetrable. It is also the type of legacy which can result in sustained outages, as systems break, and no-one know enough to put them back together again. (It is interesting to see that the emerging use of AI to tackle legacy code is often not simply rewriting or refactoring code, but attempting to discern intent – to figure out what in the world the code is supposed to be doing.)
Fortunately, there are a few ways that we can tackle persistent corporate amnesia. We can write documentation – everybody’s least favourite task until they have to rely on that documentation. We can follow style guides and write comments which provide helpful signposts and explanations (and remember that our comments don’t get tested, and it’s our responsibility to change them when the code changes). We can follow practices such as pair programming, and hold each other to account for writing code that we can actually make sense of. And, most importantly, we can organise ourselves into product teams which have ongoing, sustained ownership and accountability for the code.
Of course, none of these methods are new or surprising: they have all been established practice for years. Unfortunately, there are many places where they are not followed, or only implemented half-heartedly: it seems that we are as prone to amnesia regarding good practice as we are to amnesia about how our code works.
The other guard against corporate amnesia is our own behaviour as professional technologists. Many of our non-technical business sponsors and other stakeholders have never seen code, don’t understand that software persists, and don’t know the value of memory. When planning projects, assigning resources and organising work, it is part of our job to remind them how to make the systems they are investing in into sustainable, supple, agile business capabilities. If we forget to do that, then we have ourselves to blame.
