Code Behavior AnalysisAge of Code
How old is most of the code in your project?
Age of Code
I have a love-hate relationship with old code. By "old," I don't mean badly written code. I mean code that nobody has touched for a long time. Sometimes, the best kind of code is battle-tested, predictable, and doing its job (they're usually my heroes). However, it might be code that everyone avoids. Not because it's broken, but because nobody fully understands it anymore.
In almost every codebase I've worked on, there are a few classes like this. They're old. They're complex. And they seem to resist every attempt to keep them simple. I tried hard to prevent that from happening. I followed object-oriented principles rigorously, which worked well, until I used SQL table inheritance. It was a hilarious fail followed by refactoring of the DB schema, which was a nightmare. I also experimented with pure functions and composition, invested heavily in unit tests and other techniques. Yeah, each approach helped, but the reality is that some code just gets old and complex over time.
Why it matters
Code age by itself is not a quality metric, but it is a strong signal. When you look at the age distribution of a codebase, you start to see where stability ends and risk begins.
Old code that has not changed for years is often stable, but it can also hide complexity, missing tests, and outdated assumptions. Changing it is risky, not because it is bad, but because it concentrates a lot of business knowledge. On the other hand, code that changes frequently is usually more relevant, but also more prone to bugs and technical debt.
The real value comes from combining code age with change frequency. This makes it possible to identify hotspots: parts of the system that are both complex and under constant modification. Those areas deserve extra attention. Proper tools are refactoring, better tests, or clearer boundaries.
Understanding code age helps you decide where to invest engineering effort, and just as importantly, where not to.
Geological Time of a Planet
Your codebase is a planet with geological strata. Surface layers (new code) experience rapid change, mid-age strata accumulate technical debt, and deep layers (old code) are stable bedrock. It's usually risky to disturb without proper tools (tests). At the core lie critical dependencies with the highest blast radius; disruptions here cause system-wide earthquakes.
Fault lines appear where hidden couplings and low test coverage create instability. These danger zones trigger unexpected problems.
Cosmic analogy
How to Fix
Identify Problem Areas
- Focus on old code with high change frequency. This indicates an architectural mismatch with current requirements.
- Identify and retire dead code. These are old files that haven't changed because they're no longer used.
- Schedule regular reviews of old, frequently-changing code to prevent technical debt accumulation.
Modernization Strategies
- Consider rewriting modules where the original design no longer fits the business needs.
- Use the Strangler Fig pattern to gradually replace problematic old code with new implementations.
- Extract stable old code into well-tested libraries or services that rarely need changes.
Safe Refactoring
- Add comprehensive tests to old code before refactoring to preserve existing behavior.
Documentation & Knowledge
- Document historical context and original design decisions to help the team understand why the code exists.
- Create architectural decision records (ADRs) for new designs to avoid repeating past mistakes.