I've been thinking about how old code can sometimes be more reliable than we give it credit for. I want to bring up this idea when discussing rewrites, but I'm not sure if there's a specific term for it. Basically, over time, codebases gather technical debt through hacks, architecture problems, and unforeseen issues that weren't addressed. Even though this might lead to some bugs, it also lets us discover and fix those bugs over time, almost making the older code better. I'm looking for a term that captures this concept for a conversation about whether a rewrite is really a good idea or not. Any thoughts?
4 Answers
You might want to reference the idea of "technical debt" or even call it "code rot" since that indicates the deterioration over time. But it seems like you're looking for the positive side of aging code, which highlights its reliability after being thoroughly tested.
There’s some research on this topic that suggests code matures and vulnerabilities decrease over time. They’ve noticed that as code ages, the risks tend to lessen because issues are identified and resolved throughout its lifecycle.
Aside from "battle-tested", I think the word "mature" fits well here too. It suggests that the code has been around long enough to prove its reliability.
There's no universally accepted term, but I often refer to it as "battle-tested" code. This means the code has gone through many iterations and fixes over time, making it more reliable. I also like to use the term "crystallization" to describe how code evolves into its best form through feedback and improvements, especially after it sees lots of real-world use.
That makes sense! But we can't forget about studios using older engines for games. They may rely on battle-tested code, but that can still lead to major bugs!
I've heard of "mature" or even "hardened" code too. The more it’s been used, the more stable it can become.
That's true, but we're dealing with the upside of older code. It feels like there's hidden depth that just needs to be acknowledged.