Code can often be a liability instead of an asset.

This may seem like a strange and controversial statement. After all, clients literally hire me to write them code, and we devote so much of our time to writing code—how can code possibly be a liability?

It’s good to remind ourselves that the code is not itself the end goal and has no value by itself. Instead, what we care about is the impact or value generated from executing that code, from automating away toil, saving time, enabling something previously not possible, etc.

Recall a painful past experience having to deal with “old” code. Code has cost beyond the initial cost of development. It has to be maintained. Decisions may have to be made regarding code just by virtue of it being around. Often, the largest cost component of code is not in the initial development cost but actually in the long-term costs.

Why not just leave it alone? Why should running code that’s perfectly correct require active maintenance?

There is no such thing as correct code without the context in which the code is being applied, and the context changes constantly. That’s the thing about the external world: it changes frequently and considerably. As a consequence, functional code can quickly become outdated and incorrect as time goes on (“system drift”), and thus requiring continual upkeep to remain correct.

Let’s say we take a look and determine that the code is still correct—it doesn’t need to be changed. Does it still then have cost?

Yes. In order to remember and determine what the code is doing and whether it needs updating, one must first read the code or some representation of the code. That costs future time from future people, possibly future you. And that time may be spent forever henceforth. If that code didn’t exist, no time would be spent or wasted reading or considering it.

This isn’t a forced choice between having code or not having code. We can have more succinct, more readable code. Not all code that accomplishes the same task is equal. If there is cost to reading code, it follows that the more unreadable the code, the more costly it is. Thus, an important consideration of code quality is readability, and because code length is a large component of readability, it frequently means the least costly code is a version of the code that tends to be concise. It is as true for code as it is for writing. Brevity is the soul of wit, and succinct code is the thoughtful product of a good engineer.

Inherit an old codebase and the costs of existing code become especially apparent. Seemingly simple questions become really hard to answer: What is this code trying to do? Is this code correctly doing it? Can I trust this code to be correct in the current context? Is this code that I’m currently looking at even relevant? The more one has to read and understand, the slower it is to get productive and make modifications. But one must understand both the current state of the code and the context of the code in order to make informed and correct decisions about the code.

Given this, a guiding question when writing code could be: what is the minimal set of code needed to get done what we need to get done? That may be all the code we should want to exist. Everything else must go.

Yes, thinking about code as a liability is a bit tongue-in-cheek and invites a bookkeeping joke, but it can serve as a valuable mindset in some cases. Be careful of what you keep lying around just because “it might be useful one day”. Reconsider what you generally think of as assets, and you may discover new liabilities. Be minimalist in the projects (and their ongoing costs) you take on and aim to build only what is worthwhile (hopefully, where the value far exceeds the costs). You may even find this mindset to be one broadly applicable beyond software development.