Code Is A Liability

I love deleting code.  I like getting rid of unused code, reducing the amount of code in my code base, and making sure that the remaining code is adequate to the task.  I think that this is so important that I even wrote a series which focuses in part on minimizing code.  I think that a good developer could walk into any non-trivial environment and find, with a nominal level of effort, 10-20% of the code base which could be eliminated entirely and nobody would notice.

The title of this post, as well as my introductory paragraph, is deliberately provocative.  Nevertheless, I believe that it is entirely true.

When most people think about code, they think about the end result:  the applications.  They tend to equate “the code” with “the application.”  In reality, those are different:  a particular code base is one way to achieve a specific application result.  The application itself is an asset; people are interested in that application inasmuch as it provides use value to them.  The specific details of underlying code has no bearing on their use value of the application itself.  In other words, if you could take a million-line code base and refactor it into 100,000 lines, it would provide no direct benefit to the end user in a steady state.

So why do I push so hard for refactoring code?  The reason is that it provides value to users and to those producing and maintaining the code over time.  Every line of code which exists in an application is a line of code which somebody needed to write, somebody needed to test (hopefully!), and somebody needs to maintain.  Those are all direct code costs.  In addition to those costs, there is a cost of new features.  With an ossified code base full of junk code, writing a new feature is significantly harder; there are many more dependencies, more places for code to break, and more undocumented expectations than in a clean code base.  By refactoring code vigorously and improving the code base, we reduce the time-to-market for new features, providing additional value to the end user.

To use an analogy, let’s say that I make a wooden chair.  My amount of effort is a liability:  it is a direct cost that I, the seller, incur and which provides zero value to the buyer.  The buyer wants my chair because of its quality, not because of the number of hours I put into it.  If my process is very inefficient, I might not produce enough chairs or chairs of a high enough quality.  I grant that this analogy is imperfect, but hopefully it clarifies more than it clouds.

Advertisement