The consultant's oath

We all complain about Legacy Code. We are limited by the leftovers from previous developers. But are we not guilty ourselves of leaving Legacy Code behind?

Honor your legacy

When we talk to developers during one of our assessments we are met with almost painful honesty. Software developers will drag out the skeleton from their closet, point to it and say: “This is our problem”. Often his name is Legacy Code. Code that someone inherited, or adopted when it was left in a basket in a back alley. We even see Legacy Code used as an excuse for not doing the right thing. “We can’t automate this, it is Legacy Code”.

So when does code become Legacy Code?

When we hear the term Legacy Code we associate it with old code. Code written in Cobol and running on a mainframe. There are some annoyances around the software architecture, the frameworks, the IDE, the testing or the amount of backwards compatibility issues that arise.

Common to all these is that they make the code harder to change. So we’ll rephrase it as: “Legacy Code is code you are afraid to change”. It does not matter if you wrote the code last week or last year; if you are afraid to change it, it is legacy code.

Kill it or adopt it

You have two options regarding your legacy code. If you are no longer developing it, cut any ties to the legacy code base, and feel the burden of responsibility and the daily fear of having to spelunk through archaic code dissipate.

Or you might still be actively developing your legacy codebase. Then you have to transition the Legacy Code into the present.

And no, I’m not saying you should convert your hundreds of thousands of lines of PL/1 into C# and your problems will magically go away.

I’m saying you need to embrace a piece of software that is essential and make sure you can responsibly continue developing and releasing it.

Even if you cannot transition your project to a modern platform, or the task itself seems unsurmountable, do not despair. There are tons of small steps you can take that will make your daily work easier. Automate what you can, especially testing and releasing. Make a plan for removing the technical debt. If you have a hundred failing tests, don’t try to fix them all at once. Fix one each week. Every single time you are improving your project you will move one step further away from having to maintain legacy code.

Live by the sword, die by the sword

All of this becomes especially important when we are helping clients. We tell them to vigorously attack and eliminate their Legacy Code. But we are also producing code. We might write a few scripts, have the code miners deliver a plugin or configure a server. But what happens when our engagement stops? Did we just create Legacy Code at the client we were trying to help?

At Praqma we want to help our customers help themselves. So I solemnly swear the consultant’s oath:

“I will leave no Legacy Code behind”