Every app that’s been around for a while has code that no one touches.

The rest of the code may be great, but there’s that one area written a long time ago that everyone is scared to work on. It’s so fragile that if you touch it you’re likely to break something, forcing you to descend into its unfathomable depths in order to repair it.

If you do have to work on it, the rest of team turns somber and treats you like a soldier headed to battle. They know they won’t hear from you for a while, and there’s a chance you won’t return.

Perhaps one day you announce you’re finally going to refactor that code. “It’s ridiculous to have this awful code in our app, and I’m going to correct it,” you foolishly say. A few days later, after discovering new swear words as you try to figure it out, you decide now isn’t the best time to fix it. “Maybe I’ll tackle that after the next version ships,” you proclaim, secretly hoping nobody remembers you saying that.

When a new developer is hired, the rest of the team wants their first task to be repairing that old code. They’re new, excited to be on board, and eager to prove themselves – so let’s welcome them by throwing them into the dark pit that hides beneath our software.

But that never happens, because the people in charge don’t know about the problem. Nobody mentions it to management for fear of being assigned to take care of it.

And so the old code lingers, like a basement closet nobody wants to clean out. The code that no one touches never goes away.