In my (painfully) long career as a software engineer, I’ve often run across the attitude that code has intrinsic value. You see this frequently in the industry when ‘code reuse’ is used as a metric of efficiency. At several companies I’ve worked at, old and badly bit-rotted products have not been rewritten because “we’ve invested umpty-umph million dollars in that code, we’re not just going to throw it away.” This whole attitude is bull-doodoo, and here’s why.

If I asked you (you being a reasonably skilled programmer) to iterate over an array of integers and get their sum in (say) Java, you should be able to churn out:

int total = 0;
for (int num : numbers) {
   total += num;
}

It took me no more than 30 seconds to write that. And yes, I should check to make sure that numbers isn’t null and throw an exception if it is. Let’s assume we built the array in the same function and know it isn’t null. Even assuming that I got $100 / hour (I wish), that code is “worth” no more than 83 cents. And it isn’t even worth that really, because most of the “value” that goes into code is figuring out tough business logic, how to integrate with other systems, and running down edge cases.

Even if you knew absolutely no math, if you were literate in Java, you could take the code I just wrote and refactor it by taking a few seconds to examine the algorithm. When management talks about the value of code, they’re really talking about the value of the experience that the engineers gained by developing the code, as expressed in the code.

The problem is, most companies let the value walk out the door (either through layoffs or attrition), leaving them with “value” that the new engineers don’t understand, because the value is really the synergy of the code and the engineers who wrote it. Part of that can be mitigated with well-written and commented code along with a good process of passing on the experience to new people as they come on board. But most large systems end up as patchworks of poorly understood code because each successive engineer comes in barely understanding how the system works, and has to patch and mend blindfolded.

The cold reality that software companies try to ignore is that ANY major piece of software needs to be rewritten from the ground up eventually. They age, get bit-rotted, are obsoleted by new technology and generally become less and less supportable. A ground-up rewrite preserves most of the perceived value of the code, because the existing system can serve as a template for how the hard things were solved the last time around. Any reasonably skilled programmer can refactor from the old into the new, taking snippets of code that are still good, and rewriting the parts that have rotted.

The key is, you have to do it while the guys and gals who understand the original code are still in the building. It actually serves as an excellent opportunity to refresh their knowledge and transfer it to newer engineers, so that Phil can retire without taking the inner workings of the payroll system with him. When companies talk about the value of code and not wanting to throw it away, it’s usually code for “nobody understands it anymore, and we don’t dare touch it.”

We should treat code like a depreciated asset; the longer it sticks around, the less valuable it becomes. Eventually, it actually takes on negative value, because the potential security risks and support nightmares of bit rotted code can be huge. Embrace the freedom that acknowledging these facts bring, budget a periodic total rewrite into your business plans, and you’ll never end up with a piece of code that nobody has any idea what it does.