Age 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 mean code that nobody has touched for a long time. Sometimes it falls into the best category: battle-tested, predictable, and quietly doing its job. That kind of code deserves respect. Other times, it's the kind everyone avoids, because no one fully understands it anymore.

In almost every codebase I've worked on, there are a few classes like this. They're old and 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 - hilarious fail. I also experimented with pure functions and composition, invested heavily in unit tests and other techniques. Each approach helped, but the reality is that some code gets old and complex over time.

Why it matters

Code age by itself is not a quality metric alone. 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 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.

To identify hotspots you need to combine code age with change frequency. This combination highlights 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.

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

Age of Code Visualization

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.