I don’t like calling code bases legacy. The word “legacy” makes people think of Ivy League schools, vintage leather couches, and Dad’s old bottle of Scotch. It rarely elicits the kind of feeling of pain and despair one normally gets when dealing with old code. So instead, I prefer to call crusty old code Hostile.

Dealing with hostile code bases is a lot like dealing with a hostile enemy during a war. Allow me to explain.

The War Begins

It’s the dawn of a new day and your team of elite developers is readying for battle.

Men“, you say to them during the standup, “we are going into combat today. The enemy is ruthless and ever-present. You will see things that will scare and disturb you. You will be tested both physically and emotionally. Some of you probably won’t make it.” You pause as you scan the room, looking at their faces intently. “Just remember: it’s only code. Be strong, be determined, and be great. Let’s be careful out there!

Guerrilla Warfare

The thing about a hostile code base is that it will resist you at every step. In fact, even before you enter it, there is a hailstorm of bullets to greet you. “What do you mean it takes 2 hours to do a build?” you ask your bewildered team. “And how many unit tests do we have? None? How can that be??!!

Once you’re in, it’s gritty hand-to-hand urban combat at each turn. “We need to refactor this function, it’s over 1,400 lines of code“, you exclaim. “But there are 12 if statements in it and most are nested at least 3 levels deep” your pair says, “we’ll never untangle this mess!“. “Just do it, damn it!” you insist. “I’ll give you some cover with functional tests!”.

Land Mines Abound

Just when you think you’ve made some progress and advanced on the enemy, a land mine goes off. “For the love of C, how could there be 130 dependencies in this class?!!!” you yell in horror. “And WHERE is the source code for these 20 dlls it’s referencing? It’s still in the old Source Safe?? NOOOO….

Of course, not all land mines go off immediately. Some are time bombs, waiting patiently to go off at the worst possible time. “Production is down”, suddenly screams someone. “We’ve been getting irate client calls for the last hour. The error message says that the license key for the grid control expired. Does anyone have any idea where we can get another?!! HELP ME, PLEASE!”

The Horror, The Horror

Eventually, despair sets in. Everything gets hazy, you start questioning reality. “There are 152 projects in this solution” you whisper to yourself, “and I’ve only gone through 2 of them. In 5 days. This can’t be right, can it?”

Some of the guys on the team start to show signs of PTSD. “That stored procedure had 5 nested cursors and 2 different recursive calls in it” you hear one of them mutter with a glazed, almost delirious look in his eyes. “No one should ever see that. Ever“, he says before curling into a ball and covering himself with thousands of pages of code printouts.

Others are desperately trying to keep their sanity, grasping at any straw that may offer even the tiniest glimmer of hope. “This class doesn’t have any functions over 10 lines of code in it!” says one cheerfully. “Yes, but it’s just a proxy class which does nothing but wrap members of another class, for no apparent reason”, you answer. “Yes, but this class doesn’t have any functions over 10 lines of code in it!, says he once again, with a crooked smile and eyes glistening. You see a tear roll down one of his cheeks and you turn away.

The End?

I really wish this story had a happy ending, but that’s certainly not guaranteed. In fact, hostile code bases can easily turn into your Afghanistan, the graveyard of projects. But don’t let that stop you, you need to get features implemented. So fight on, brave developer, and may the gods of code have mercy on your refactorings.

You may also like:

Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!

This post got 12 comments so far. Care to add yours?

  1. nick says:

    We have a way to deal with legacy code bases. We retire them.

  2. Aaron says:

    Thanks, I like the metaphor. Bearing in mind that one must defend against the unknown tricks and traps of old code certainly is useful. One thing I’d change is the implicit gender assumption — my team is 50% female, a relative rarity.

    • Alex Tatiyants says:

      Thanks for your comment Aaron. As for the gender assumption, that was done for comedic purposes only. We too are lucky in that our team has excellent female programmers.

  3. Tim Daly says:

    Literate Programming. INSIST ON IT. Literate programs are written to communicate idea
    and their reduction to practice to other humans who will never talk to the original authors.
    As a side effect a literate program also implements the ideas.

    If your company depends on a piece of software then you MUST write the software to “live”.
    Programs live when other programmers can understand and maintain it. That requires that
    the original team communicate the ideas as well as the implementation.

    Never let a programmer check in a piece of code without a few paragraphs in your native
    language explaining WHY the code exists and what it is trying to do, what the challenge is.
    This has 3 vital effects:

    1) the original programmer writes better code because they have to explain it
    2) the group code review can question assumptions and ensure that the explanation
    covers what the code does and why it does it
    3) once the original team leaves the code can be modified and maintained.

    Can your code pass the “hawaii test”? Hire a new programmer. Give them your literate
    code. Send them on a 2 week, fully paid vacation to hawaii. When they return they should
    be able to maintain and modify the program as well as the original team.

    Stop writing hostile code.
    Raise your standards.
    Become better programmers.
    Communication matters.
    Write literate programs.

    Tim Daly

  4. Geronimo says:

    “On the battlefield, there is no place for design patterns.”

    • Alex Tatiyants says:

      Excellent point Geronimo. Also, “In war, truth is the first casualty. Tests are a close second”.

  5. This is Armageddon! My advice is to choose your battles carefully.

  6. Christopher P. Kile says:

    Let’s see…I’ve made about half my career turning hostile code into friendly code. In my current position, one of the most hostile pieces of code that I maintain is about to retire, and it couldn’t be too soon for me as at least two vendors that supplied controls vital to this program’s operations are no longer in business, and support is relegated to readmes and terse API references. You keep it until you understand it, then you carefully replace every piece of it that depends on something that might disappear or has disappeared (a vendor, a language, an operating system) then (because you understand it) you refactor it. This requires an enormous amount of intestinal fortitude, because you’re going to have to tell the boss at some point that it’s not going to be easy and it’s not going to be over until it’s over, and you have to sell him on that – and if I liked sales that much, I would have stayed in sales instead of becoming a programmer. Worst recent experience in that vein was a COM control that, suddenly, no longer seemed to work in IIS 6.0, and its vendor had been dead for eight years (we had the API reference, so we were able to code with it, but that was it). Thankfully, I found a free control on ASP.net that replaced the functionality and expanded it immensely – I just had to rewrite every line of code that referenced the old API. That’s what I get paid for – I’m sure the police bomb squad says it the same way. Hmmm, maybe I’ve been in the foxhole too long, but the smell of the gunpowder keeps me revved up 😉

  7. Real Exams says:

    War begins there.