Legacy code as a trap

As a developer, you will get requests or assignments to make you work with legacy code sooner or later. I'm not talking about the kind of legacy code that we wrote ourselves. That can be bad, but at least it sounds reasonable to assume responsibility for our work.

I have experienced unpleasant situations, wishing I had said "no" much earlier. But if we want to do any work that might include existing code, we need a more differentiated view, so let me share some heuristics that might be useful and some strategies to mitigate risks and responsibilities.

Legacy code, easy and risk-free ✅

Fixing or extending legacy code that others wrote can be relatively easy and risk-free

• when adding an independent module
• when using a documented framework
• when there is good test coverage.

But often, we will have to modify existing custom code that is neither well documented nor covered by useful tests. How can we be sure not to break anything if we don't know what the code does? We can't!

Contained risk, no critical danger ⛑️💥

While not risk-free, it can be okay

• when errors can't break orders, payments, or critical infrastructure like traffic or healthcare
• when code is only deployed after senior developers and product owners have tested and approved our changes
• when we can earn a lot of money for making those changes.

It's probably not okay.....

• when errors can break orders, payments, or critical infrastructure like traffic or healthcare
• when there is only one production system
• when there are already a lot of errors or erratic behavior
• when we risk losing our own money and reputation.

The last is the worst: fixing legacy code can become a trap!

Legacy code as a trap 🪤🕸️

You might think everything's fine when you see there is version control, and another person will have to approve your merge request. But some people are only looking for a scapegoat, someone to blame for known but undocumented errors, and point their fingers at you because you were the one who committed the latest change before a critical error was reported.

What to do? As a freelancer, you are free to refuse an offer unless you have already signed a binding contract. But even when you did, it might be better to lose a customer or pay a contractual penalty - a known risk that you chose to take when signing a contract - than to proceed and take a much bigger risk of losing time, money, and reputation.

As an employee, you have limited freedom but also limited responsibility.

Red flags when working with legacy code 🚩

If you have any reason to fear taking the blame for other people's errors,

• because of an unusually messy and unstable codebase
• because of a toxic work culture
• because all your predecessors quit the job hastily
• because your contract contains costly contractual penalties
• because of any other "red flag" gut feeling ...

Reduce the risk! 🦺🛟

... but you are still willing or have no alternative to do the job, be extra careful, take your time and make sure you get a proper (monetary) compensation!

You can also try to contain and reduce the risk

• by insisting on unambiguous requirements in writing
• by communicating verbosely in writing (people might "forget" what they said to you)
• by making local copies of requirements, communication and code commits (they might be edited or deleted on a server, or you might lose access to it, but make sure you delete them later according to legal and contractual requirements)
• by insisting that you need more information, support, or reviews
• by claiming that you are not able to complete a task
• by prolonging discussion to prevent shipping.

We don't want to behave like that and become mistrustful or paranoid, but these are some possible strategies to help avoid the worst outcome when we find ourselves in a critical situation.

Try to stay positive, never blame the wrong people and never forget that making errors is an important chance to learn!

A chance to learn and improve 📖↗️

We can

• analyze the situation
• narrow down problems
• sharpen your senses for "red flags" vs. irrelevant aspects
• consider better alternatives for future situations
• avoid getting into a similar dilemma again,

and if we do, we know that we are able to protect ourselves and get out of the situation eventually.