Examined Competence: The Birth of Legacy Technology
And so the team resolves to follow the path of least resistance. They dutifully update the unit tests. They also manually test the relevant changes, because they have learnt from experience that unit tests are only half the story. The code is successfully deployed without problems, everyone breathes a sigh of relief, and congratulate themselves on a job well done.
— Rajiv Prabhakar
Target Article:
The Birth of Legacy Software:
How Change Aversion Feeds on Itself
by Rajiv Prabhakar
Target URL: The Birth of Legacy Software (link)
n.b. I write “Examined Competence” for a weekly internal newsletter. The primary audience is my peers in our enterprise IT rotational program.
I copy the story both here and to my personal blog (thecarolinatechnical.com) for the purposes personal reference, general viewership, fame, and glory. Some specific detail are redacted before publishing here.
Introduction
In this post from his blog “Software the Hard way — Thoughts on Software Development,” Rajiv describes the birth of legacy software. Or put another way: how software becomes legacy software despite the support of a well-intentioned, risk-averse development team.
Rajiv argues that an aversion to change — given sufficient time — can cause a team to make decisions based on reducing the problem space, reducing risk. After all, they can’t fully trust a system that nobody fully understands. Not anymore, at least:
They identify a way to avoid making significant changes. “Right here, in method Foo in class Bar, just add another if-check, a service call and/or a dependency to class Baz.” This way, the changes will be only a couple lines of code. Far less risky.
Editor’s Commentary:
Please read this article, and think how it may apply to the digital systems you use in your work. It can be so easy to explain away Hard Problems as the result of incompetence, bygone leadership, or entropy. These are great targets to blame. By blaming incompetence, we know that we will never be responsible for creating legacy software, so long as we can avoid being incompetent.
And that is actually a pretty tidy problem to solve! In fact, Hard Problems do not have easy solutions. I do not wish to exonerate incompetence, but to highlight an uncomfortable reality: it is wrong to expect that we can find an easy, workable solution to every hard problem — despite our technical competence, motivation, or good intentions. Sometimes, the only way to move forward is to address the complexity in our work.
Some Questions…
- Have you ever worked with legacy software? If so: why do you think it is such a pervasive problem?
- What insights from the target article did I fail to cover in this post?
Any feedback is appreciated — thanks for reading.
