Some Technical Investments Age Like Wine. Others Like Milk.
Not all systems depreciate. Some get more valuable over time.
The Problem
We talk about technical debt like it’s inevitable.
Build something, wait a few years, now it’s debt.
But that's not quite right.
Some things I built 10 years ago are liabilities today.
Others are more valuable now than when I built them.
What's the difference?
1. What Depreciates
A monitoring system built in 2015 following Google's SRE principles—
dashboards, threshold alerts, searchable logs-
was solid engineering at the time.
Today it’s debt.
Not because it broke. Because expectations moved.
The new baseline isn't “engineers respond quickly.”
It's “systems detect and suggest before engineers notice.”
Investments that depend on human speed and
expertise depreciate as automation expectations rise.
2. What Appreciates
A CI/CD pipeline built in 2015 - with automated deployment,
consistent environments, and a regression test (+ Git trails & Jira records)
for every production bug - was good practice then.
Today it's a strategic asset.
This historical information becomes a foundational resource for:
→ AI-assisted development: to train AI-generated code today.
→ Continuous verification: to suggest what to watch for today.
→ AIOps integration: to create causation RCA models.
The same applies to well-documented API contracts,
structured decision logs, or any artifact where
past reasoning is machine-accessible.
3. The Pattern
Investments that encode decisions into automation
appreciate as AI amplifies them.
Human-dependent → Depreciates
Machine-readable → Appreciates
4. The Implication
When deciding where to invest engineering effort, ask:
→ Does this capture knowledge in a form machines can use later?
→ Or does this depend on humans being fast, experienced, and available?
The first compounds. The second decays.
5. Why This Matters
A company with a “legacy” system that has 10 years
of historical information? That's not debt. That’s GOLD.
A company with modern dashboards but no test coverage?
That’s fragile, no matter how pretty the graphs.
The age of the system matters less than what it captures.
I call this the 'Data Gravity' principle of Technical Economics.
If you are rewriting a 10-year-old system,
don't just ask 'Is the code old?'
Ask 'Is the data history machine-readable?'
These are the decisions whose consequences
only show up years later —
which is exactly why they matter.