Hostile Code Bases

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.