Degradability
The software quality metric no one measures and everyone pays
6 min read
Jun 15, 2026
--
--
A cracked binary clock on a concrete wall. That's it.
Most software quality metrics measure what happens when you change code. Test coverage, cyclomatic complexity, defect density. All of them assume active development.
None of them ask about the most important question of all:
> What happens when you stop?
I started thinking about this after looking at the 1996 Space Jam website. Warner Bros. built it to promote a Michael Jordan movie. Static HTML, an image map, a repeating star background, and a screen resolution nobody uses anymore. The site sat untouched for 25 years. In 2021, it still worked. You clicked around, read the behind-the-scenes copy, downloaded browser icons for a computer you haven’t owned since high school. It all loaded.
I call this **High/Low Degradability**.
That site has low degradability. Leave it alone, and the cost of returning to it stays near zero. The world moved on and the page didn’t care.
Now think about the last Node.js project you abandoned for six months.
1. You came back. 2. You ran `npm install`, `pnpm install`, `npm audit` or whatever 3. The terminal gets filled of deprecation warnings and a dependency you never directly imported broke: the server it pinged at build time went offline 2 years ago and the package hasn't been updated since the last World War. 4. Your CI pipeline failed on a Node version that your host provider stopped supporting.
I recently saw this issue running a security audit on an apparently "clean" main. Dependencies were not updated and new vulnerabilities were discovered since the last run.
Nothing in your code changed. Basically the **COST** of returning went up on its own. That project has high degradability only because **TIME** alone made it **WORSE**.
> **Degradability is the rate at which idle software accumulates re-entry cost.**
It measures how much work you face when you return to a codebase you did not touch, not from bad code on your part. The world kept moving and your software was coupled to parts of it that moved.
The concept is different from software rot, which describes a general decline in quality or performance over time. Software rot is a diagnosis. Degradability is a property you can measure before the rot starts, and a property you can design against.
Get Fayner Brack’s stories in your inbox
Join Medium for free to get updates from this writer.
Remember me for faster sign in
Three components drive degradability. Each one is a surface area where time creates cost:
**1. External dependency count**
This is the most obvious driver. Every third-party package is a bet that someone else will keep maintaining it. Aqua Security’s research on the npm registry found that about 21% of the top 50,000 most-downloaded packages are deprecated, unmaintained, or have archived repositories. Those packages get downloaded roughly 2.1 billion times per week. A single deprecated package like `request`, at the time of writing this still has over 53,000 direct dependents. Each one of those dependents inherits a liability that grows with time.
Here's the simple math: if you depend on 200 packages, and 21% of the npm ecosystem is effectively unmaintained, you are exposed. Not today. In six months, or twelve, one of those packages will stop working and your build will break. The more dependencies you carry, the shorter your safe idle window. That is, assuming 21% is a constant…
**2. Runtime environment coupling**
This is the second driver. Your code runs on a platform, and that platform has a release cycle you do not control. Node.js major versions reach end-of-life on a fixed schedule. Cloud providers deprecate APIs. Browser engines drop support for features. If your software assumes a specific runtime version, the clock is ticking from the moment you stop updating.
The Space Jam site survived this by assuming almost nothing about its runtime. Static HTML rendered in 1996 browsers. It renders in 2026 browsers too. The less your software depends on a specific version of its execution environment, the longer it can sit idle without breaking.
**3. External service coupling**
This is the third driver, and the most unpredictable. Your test suite calls a staging API; a build script fetches a font from a CDN; a linter downloads a shared config from a URL… Each of these is a network call to a server you do not own. If that server goes dark, your pipeline stops. Unlike dependencies, where you can audit a lockfile, external service coupling hides in scripts, CI configs, and post-install hooks. You often don’t know about it until you come back and the build fails.
> **_A codebase with low degradability can sit idle for a year and cost you a day to resume. A codebase with high degradability can sit idle for a month and cost you a week or months._**
Ok but how do you actually measure this?
I think about it as a rough function of three inputs: the number of external dependencies, the number of pinned runtime assumptions, and the number of network calls made outside your application code during build, test, or deploy.
Score each on a scale. Start by tallying your direct dependencies and the places your build or test process calls an external URL. Then check the runtime version constraints in your config files. A project with 12 dependencies, zero external build calls, and a loose runtime constraint scores differently than a project with 340 dependencies, four CDN fetches in CI, and a pinned Node version in `.nvmrc`.
There is no magic threshold. But the comparison is useful. When two projects sit side by side and one will cost you three days of catch-up after six months of inactivity, and the other will cost you an afternoon, you can ask why.
The answer is usually one of those three components.
This model doesn't cover everything. It doesn't account for internal code quality, team knowledge loss, or documentation decay. A codebase with perfect dependency hygiene can still be impossible to resume if the only person who understood the architecture left the company (see also Bus Factor). That is a real cost, but it is a people problem, not a software property. Degradability is scoped to what the software itself does to you when you leave it alone and, of course, can also be applied systematically to organizations and any other closed system.
The framework does not address active development either. A codebase that rots from constant patching without refactoring is a different failure mode. Degradability is about what happens when nobody touches the code at all.
See also the concept of Entropy from the Second Law of Thermodynamics.
I keep coming back to the Space Jam site. It had no package manager, no build step, no CI pipeline. Just markup and images on a server. It is the theoretical floor for degradability: a codebase with almost zero coupling to the outside world.
That is not a realistic target for modern software. But it is a useful reference point. Each dependency you add moves you further from that goal to keep degradability low. A pinned runtime version does the same, and so does an external URL your build touches. The question is not whether you can get to zero. The question is whether you know how far away you are, and whether the distance is growing or not.
Most teams track what their code does. Very few track what their code needs from a world that will not wait for them.
If you liked this, you might like Readplace, built for exactly this kind of reading.
Thanks for reading. If you have some feedback, reach out to me on LinkedIn, Reddit or by replying to this post.