We live in the age of Code Abundance.
It’s never been easier to write, run, and subsequently share a piece of code. The whole Github + software eating the world phenomenon of the past 5 years has increased both the amount of code as well as its applications.
Stepping back, it’s also clear that while code may be replacing industries and fostering incremental efficiencies, software not necessarily creating new value (e.g., entirely new industries) in proportion to its abundance. In other words, not every line of code is adding the same amount of value to the world; most of it is displacing existing value1. To put it yet another way: the value of code does not scale linearly.
The corollary is then evident: every written line of code reduces the average value per unit of code. More abstractly, we as a society are writing more code than ever, but each line, function, module, system by itself is less valuable. This is reflected in the amount of abandoned and lost code, the number of systems which are invented and reinvented up and down the stack, and perhaps the disposable nature of apps and websites.
If the half-life of code is shrinking, does that make a statement about the nature of code quality? Should longevity be an important factor for how code is perceived, regardless of how ugly or how it may be out of date with modern best practices (e.g., no tests)? How much value should we place on resiliency2?
Admittedly, “value” is a tricky concept to define, even as I throw around the term like my toddler throws vegetables on the ground. In our capitalist system, a reasonable heuristic may simply be “something that someone is willing to pay for.”↩
Fun exercise: try to see whether how long a system is running after you’re no longer to evangelize, support and maintain it. For instance, I know for a fact that the my initial project at Google no longer existed a mere two years later.↩
