“Code is a liability, the functionality is an asset.” I remember finding this statement counterintuitive. Somewhere along the way it transitioned to feeling like an obvious truism. I think it’s worth spending some more words on this phrase, exploring why it is so important, and what it means for software projects.
In a cognitive economy, most of the value we add to a company comes in the form of cognitive assets. Intuitively, code seems to be such an asset: If my employer owns a piece of code that predicts electricity production of wind turbines, does that not increase the company’s value?
Well, it does two things. On the one hand, it adds value because the company now has access to a tool to solve a particular problem. Every time it uses that tool, it generates real added value and ideally a return on investment.
However, at the same time, it also incurs a cost for the existence of that tool as it needs to be maintained, things break, technology goes out of date. The company has made commitments based on the continued operation of the tool and if it suddenly stopped to work, the damage would be painful. Because it owns the code, the company needs to be concerned about several risks such as the last person that still knows how the code works leaving.
This makes it clear that the asset is the fact of being able to solve a particular problem. The code that you write for this is a liability. If you could achieve the same effect with fewer and less complex lines of code, the company would possess the same asset but hold a smaller liability on the other half of the balance sheet.
When code is written to achieve your primary business goal, the math may very well check out as the value provided by far surpasses the long-term costs. It gets much trickier, however, when it comes to code produced to solve peripheral problems or as a part of an in-house solution to support certain business processes.
For instance, as you are building a tool for the prediction of electricity generation and you notice that the library that you are using for UI components is lacking in some way, would it make sense to write your own? You rely heavily on parsing XML files but the existing parser consumes too much memory, should you build your own? (Yours truly may or may not be guilty of writing a custom XML parser in one of his previous lives).
These are tricky because there are instances where the answer is yes. Such custom tools might unlock new areas of the solution space. However, I would argue that in many cases we underestimate the long-term cost of such custom solutions. Imagine building a solution on top of your custom XML parser: Suddenly you are committed to maintaining that thing. However, it does not directly contribute to solving the business problem and maybe all of this would not be necessary had you, for example, selected a different exchange format in the first place.
Misaligned Incentives
You may have noticed that I am particularly interested in dynamics that cause misalignments between an individual’s incentives and the goal of the organisation. This example is one of the areas where I think the incentives of your engineers deviate from the interest of the organisation. Take Gergely Orosz’ take on promotion driven development for example:
Software Engineers do not typically have an incentive that encourages producing as little code as possible and only solving the problems that directly contribute to a company’s output. Instead, status and promotions are attached to the ability to solve complex problems irrespective of whether or not these are the right problems to solve. It is not always in the best interest of an engineer to say “my work here is redundant because there is already an off-the-shelf tool that does the same thing”.
In conclusion, I think it would be helpful for organizations to adopt a mindset that producing a line of code is similar to taking on a small debt. The consequence of this realization is an increased focus: Accept the debt in places where you expect a high return, but don’t if the long-term added value is questionable.
The Solution Space 