Anyone who has written more than a handful of lines of code gains the intuition that measuring productivity in terms of code quantity is not a promising approach. But the perception that a codebase is an asset - whether proprietary or otherwise - is present even in engineering cultures.

How do we explain that having code is worth something, but measuring work in terms of writing it isn’t? One answer is that lines of code are valuable, but in such a nonlinear and context-sensitive way that counting and assigning some sort of score is futile.

I find that perspective compelling - but incomplete. To understand why code is valuable we have to first ask what a codebase really is.

If you’ve ever bought something with a loan, you’ve likely had to make periodic payments to, over time, liquidate the debt. This is called amortization - etymologically derived from “to kill” and “death.”

The reason for this grim phraseology is that these periodic payments really are eliminating something - an outstanding debt. The debt is “alive” in that it probably generates interest of some form, so to effectively pay it down requires enough not only to address its growth but also chip away at its principal.

What does this have to do with codebases? The concept of technical debt is seen as an accumulation of defects, from shortcuts and other compromises - something that may accompany a codebase, but a side effect and not an integral mechanism.

In any project with scope that requires a timeline (even implicit), technical debt and the codebase are inevitably and intimately related. Much like a debt-financed purchase, creating a codebase that has a time dimension means creating a present commitment predicated on future payments. And much like a financial investment, the value of a codebase can shift up or down as or after we pay into it, and these shifts can sometimes be anticipated and other times occur due to chance.

The nature of payments when working with code is trickier to measure - but at a high level, code is a product of structured thoughts, or intelligence. And so when we work on a codebase we are paying intelligence into an inherently debt-driven structure, a promise of present and future value conditional on ongoing intelligence-debt service. Like a loan, a technical project is a commitment, serviced over time.

Seeing technical debt as the cost of shortcuts is a simplification - all planned work involves a process of iterative consideration and refinement, even and sometimes especially when it is well-engineered. Debt is a promise and system, one that can easily cause harm when mismanaged, but also the primary way to get big things done. Financial loans aren’t intended to simply shift money around for the sake of it - they are meant to enable projects and work.

Obvious technical debt (like monkey patching a dependency) still matters, and is the “high-interest credit card” of this perspective - something to be used situationally and only when you know you can pay it off promptly. But recognizing that all “long work” involves debt and payments allows us to see the value we accrue as we chip away at it (and perhaps facilitate better planning as we go). The codebase is still an asset, but encumbered by its nature to be more of a process than a result.

The value of code isn’t just nonlinear and context-sensitive - it’s time-variant. The resulting artifact - the codebase - is the accumulation of amortized intelligence. And of course, the real value comes from the actual utility to the end user.