Oh, Dear! Contagious Legacy Code

In my previous post, I talked about anchoring bias, and how it affects the evolution and quality of our legacy code. I’ve argued that when working with legacy code, developers allow themselves things (in terms of quality, usually) that they otherwise wouldn’t.

I’d like to continue talking about legacy code but from a different perspective. It is widely acknowledged that legacy code, while a necessary evil, causes technological complications. Less widely discussed, however, is the social cost. Legacy code can deeply impact our everyday interactions with our colleagues, and common management patterns cause our psychology to further dig into the legacy mud, with no way out.

Using behavioral psychology, I’ll try to make the argument that legacy code is destined to continue being an issue unless proactively addressed.

Being the “legacy system guy” is a lonely road to travel

Years of evolution have taught us that diseases can spread through touch and proximity, it’s our biology. Our psyche addresses this biological aspect according to the contagion heuristic and classifies our experiences and interactions as “good” and “bad,” trying to avoid the “bad” ones.

The same classification applies to places, food preferences, people, friends, colleagues, etc. For example, if you have a nemesis at work, and you’ll see your colleague Bob complementing them in a meeting, your psyche might consider Bob “contagious” — you’ll lose respect for him and try to avoid Bob going forward.

Your legacy code is an experience easily classified as a “bad” one. You don’t enjoy it, it’s complicated, and you’d prefer doing other, more innovative things.

Due to the contagion heuristic, our psyche might classify those colleagues who maintain the legacy systems as contaminated by it, causing us to keep our distance.

Every company has this one developer who is the legacy component “go-to person.” I was that person at some point in every company and project I ever worked on. I remember the feeling of knowing the legacy component too well and knowing that every feature development required will land in my lap.

In one of my previous roles, even after management acknowledged that a bus factor of one is unacceptable and decided to spread my knowledge across multiple devs, I would still end up dragged back in at the first sign of trouble.

After I became contagious — after the entire project became contagious — getting people to agree to work on it became an impossible task.

The worst part, though, was that I was classified as “outdated” — both by my management and by my peers. My technological stack, knowledge, and view of how systems are developed and should be designed was classified as “legacy.” I wasn’t considered when developers were chosen for innovative projects, or as POCs for new technologies. When extra working hands were needed for other projects, my technological stack didn’t allow me to offer any assistance.

I tried teaching and passing my knowledge to other developers in the team, and suggested several ways how I could move on to more modern technologies, but all attempts failed due to lack of managerial support. Eventually, I left that workplace, leaving a knowledge gap behind me.

Inoculating an organization with legacy code

How can we fight this basic human instinct? I can’t believe I’m writing this in the COVID-19 era, but there are two steps:

1. Make sure everyone is “infected” — fortunately, it’s only software, not a real disease, and we have the privilege of infecting everyone with the “legacy component” in a controlled way: make sure the whole team is infected, and social immunity will build up. If all devs in the team work with the legacy component in addition to the “good” tasks, no one is contagious and everyone shoulders some of the burden.
2. Mandatory distancing — make sure that after someone comes into contact with the infection (the legacy code), they are distanced from it for some time. This means that even when a dev suffers from a legacy maintenance task, they know that after it they will be “rewarded” with a “good” task.

Over time, this will create a balanced and well-adjusted team.

Closing thoughts

Today’s cutting edge is tomorrow’s legacy. Therefore, legacy software will always exist, and we must choose how we manage, maintain, and work with it, as well as who the people keeping it afloat are.

If a task is so important that it needs to be completed fast — it’s for sure important enough that you need more than one developer to maintain it.

If you’re that contaminated me from a few years ago, don’t hesitate to be proactive and push for peering with your teammates:

• Team up with someone on their tasks to learn new technologies
• On tasks that involve legacy code, partner with one of your teammates, and share your knowledge.

If you’re a manager that has such a “contaminated” person on your team, make sure you are on top of things and think about how you can distribute that legacy load better. It’s not fun to be “it”.

Keep in mind that any company’s biggest asset is its employees, far more than any product or system, just due to the sheer fact they are making it, and it wouldn’t exist without them. Part of being a manager is making their working environment as positive as possible, and legacy code, as we’ve seen, is a big part of that.