Code Rot: When Good Code Goes Bad
Why does code rot? Wikipedia lists a bunch of reasons — some make sense to me, some leave me meh.
From the vantage point of my battered years of experience, I’ve come to classify code into three areas:
The code your company creates, the code that is an expression of your company’s competencies. The software you sell, or the software that you use to sell services. Your bread and butter.
This code is known, it is under active development. Multiple developers work on it. There are people discussing the code, actually designing solutions to problems.
People use this code.
The code you buy, or the free/open source libraries you use. You know what it can do — you may know the API better than the source organization in some respects. You follow updates, upgrade versions, may even have a developer on some mailing lists.
But when push comes to shove, if something is really wrong, you can ask for help, either through paid tech support, or by relying on the good will of strangers. Nothing wrong with that; I do it myself sometimes.
So you have a plan for problems. Good on you!
We all are familiar with this code. Code someone in the company wrote, or hired someone to write, some looooong time in the past. The code does it’s job, but none of the current developers has seen it, held it, felt it in a while — no one holds the shape of the code in their head any longer.
When a change needs to be made, it is approached with trepidation and macabre commentary. Developers poke and prod at the code blindly, hoping to fix problems. This is software archeology at its finest.
The development team resists making needed changes and improvements, because the terror factor is too high.
Note that this does not mean no one is responsible for the code, or no one owns the code — this is far more profound. No one has even looked at the code in so long, there is no one left at the company who remembers how it gestated.
It’s not your code, it’s not their code, it is just … a blob of code that no one understands. There is no one to call, no mailing list to ask questions of. Just a blob of code.
A blob of code that is a threat to your codebase. Code that represents a potentially enormous technical debt — an adjustable rate mortgage whose terms are unknown, written against your team sometime in the past. Who knows when the debt will get called in?
Nobody’s Code is Rotten Code.
So what do you do?
In a perfect world, you excise the code, throw it away, jettison it, make the case that you don’t need the code and its functionality anymore. Good luck with that; removing features from commercial software can be a brutal political and managerial mess and a customer nightmare. I’ll ignore that lovely option, you’ll rarely have it.
I’ve only found two real solutions to this case. You can reclaim the code, or you can replace the code. You cannot, however, ignore the code.
To reclaim the code, you’ll need to do two things. First off, someone on your team has to do a really deep dive into the code, writing new tests, trying to break the code. (Everything you break expands your understanding, so tests which break stuff are much more interesting than tests which work.) Then, when your team member(s) think they understand it, you need to generate a planned set of improvements. Not just tiny incremental stuff, moving icons around — you need to do some major rewrites if you really want to reclaim the code. Don’t be shy; this is the time and place for daring. Wade in and reclaim the code.
The downside of a reclamation plan is easy to see: lots of time and resources. Rarely can you take a star performer and burn them on a task like this. It will also likely be a helluva tough sell to your bosses.
Replacing the code is almost always more attractive to young developers; they have yet to learn to respect code that works. Though, let’s be fair: I know of no developer who doesn’t get a little excited at the prospect of replacing a large chunk of mature code. We’re all much happier writing code that reading code.
But replacing code has large problems too. Working code is precious; replacing can be really risky to your business. And again it can hard to convince your bosses to spend the resources. And only idiots think they know how long it will take to replace a complex piece of code they don’t understand.
Frying Pan/Fire, meet Rock/Hard Place.
Both options are unattractive (aren’t we supposed to be building new things for our customers?) but the alternative, ignoring your rotten code, is far, far worse.
Behind Door #3 is Nobody’s Code. Rotten Code. The worst code of all.
P.S. Dancing Bears are emphatically not rotted code — they are a completely different form of technical debt.