« The Urge to REPL, the Urge to Test | Main | UML Out of the Box »

May 17, 2011


TrackBack URL for this entry:

Listed below are links to weblogs that reference The Carrying-Cost of Code: Taking Lean Seriously:



When writing code, I always try to ask myself "will this code pay for itself?" (and idea borrowed from Josh Bloch I think). And it's easy to spot a piece of code has stopped paying for itself, but that's usually long after the fact.

The 3 month experiment aside, how do you decide this? Is code like any other asset that depreciates by a fixed amount over time, until you eventually write it off?

There are some artificial milestones:
- when someone leaves/is leaving, someone on the team rewrites parts of the code the departing developer was responsible for.
- an update to a new release of a core technology (e.g. the appserver, or the language or whatever) should trigger a cull to make optimal use of that release. Instead what happens is you end up with a mixture of code that uses the newer features, and code that does things the old way.
- use source control to guide changes. e.g. the top 10 most modified classes in the last six months that are twelve months or more old need a rewrite

Of course, the potential for abuse is enormous and convincing management types that putting effort into rewriting something that's already working will be a very hard sell.
But a long lived code base that doesn't get refreshed regularly turns into every growing islands of "don't touch it, it just works". Which is fine, but eventually, you DO have to touch it.


I forget the source, but I've seen it stated something like this. In accounting terms:

Features are an asset; code is a liability.

It was further suggested that lines of code should be included in technical debt metrics. EVERY line of code is technical debt, by definition.

This makes a lot of sense.

[Anyone remember the source? It was a great article.]


How about using monitoring/probing of production code to find out what are the most used features and which ones are seldom or never used? Having those kind of metrics would help drive say a story every release to rip out an unused feature to reduce code bloat & complexity.

Of course if we continue with your car analogy, we wouldn't want to remove the emergency brake because it is rarely used!

Grechen Wilson

Of course your own code isn't ugly, only other people's code. This sounds like a elitist at work.

Anders Eurenius

@Grechen: He didn't write anything close to that. and so what if you can't see the ugliness in your own code? Do you expect to be able to accurately evaluate merits of anything that's your own?

Bernt B

A corollary is to use as high level languages as possible; you need fewer lines of code per given feature.

(So why do my bosses insist on moving to Java in 2011!?)


Instead of having few modules and a master file to call in, we should break the entire stuff into different modules according to the business needs defining the use and what feature it refers. We can also have small reporting system which can calculate or find out the usage frequency of the particular module by finding how many times that module is called by the user to avail the feature. This makes sense to cut down or freeze or take critical decision on seldom used code (feature).

Benjamin Klein

@MetaThis: See Ted Dziuba's post "Taco Bell Programming," at http://teddziuba.com/2010/10/taco-bell-programming.html. (No attribution is given in the post.)

Dave Moran


Your concept about deleting code and rewriting it is interesting, but going so far as to eliminate features while you are doing it would cause some anxiety, even with the focus limited to those features to those that aren’t used or rarely used. People hate taking things away! One way to aid the business call is to add profiling the app so that you could prove which features weren’t actually being used and then calculate the carrying costs of those never or rarely used features. And if some features haven’t needed to be modified as the result of adding other capability, wouldn’t you be unnecessarily adding to the carrying costs by rewriting the code?

I blogged about source code recently myself, but my take was that it was actually an undervalued asset.


Prashant Gandhi

Code as an inventory is so much more intuitive than requirements as inventory. I also see unused features as inventory and therefore, a good way to clean up code is to remove those features that no one has used or are likely to use.

In my opinion, Code is an asset, not a liability. Some code qualifies as non-performing asset and they need to be either cleaned up or deleted. In a balance sheet, assets are also listed in the sequence of how liquid they are - fixed asset at the bottom and highly liquid asset at the top. Extending the metaphor, maintainability of code can be substituted for liquidity.


Every project I work on these days gets a "graveyard" folder to put dead code in:



If we can find a way to automatic remove non-used features, that would be great.
In hosted website app, that should be easy. If a feature has not been used in 3 months it goes offline.
I guess most (all) managers would agree to that, they would think, yes but every feature will be used at least once by "A user".
Hey even I think that.
Yet I know that I (and these managers with me) will be very surprised about the results



I like the analogy of code as inventory, makes me think that by far the most costly inventory is code that hasn't been shipped. Unshipped features are by definition unused and the process of fine tuning new code both operationally for user experience is expensive. If you have a lot of code that hasn't gone through this process you are hurting yourself the same way a manufacturer would with a big pile of unsold inventory.

Bruno Michel

@MetaThis: maybe "Code is Liability not an asset" - http://dev.af83.com/code-liability-not-asset-part-1-3/2010/02/24


I think you strategically delete code like you might preen a bonsai tree. When then the bonsai tree pisses you off or looks ugly you delete it and start again.

But code is not inventory. It’s scaffolding, that may or may not be well erected, that the business uses to do its jobs. The scaffolding can always be taken down, replaced, etc.. The code is not an essential part of the business, it’s accidental – like inventory – but unlike inventory does not become part of a product only part of an enabler.

Jon Reid

Alex Stepanov gave a talk at Adobe: "Companies think software is an asset. It's not. It's a liability. The asset is your accumulated knowledge and experience." He then demonstrated, on real Adobe code, how a long function could be reduced to a few lines.

Account Deleted

I like your analogy of seeing code as inventory. but i have a question on this.

What are the competitive advantage that companies can avail by removing unnecessary features/ delete code?
-> Is it the maintenance cost of non essential features? Or
-> Maintenance of code (repository maintenance etc.)?

What are the benefits from developers point of you?

Harrison Ainsworth

Instead of talking of 'carrying' code -- Dijkstra frowned on that kind of metaphorical thinking (sensibly so) -- it might be clearer to rephrase and summarise this in more straightforward terms.

The problem here is that larger code is more complex, and more complex is harder to work on. The suggestion is that we impose limits on the amount of code. That seems somewhat prudent, but it does not really attack the problem: we want to make code easier to change *despite* it being more complex.

Just limiting code size is not really a solution. Very broadly, functionality is proportional to code size (in general, and in particular where all else stays constant -- is that not reasonable?). So limiting code size is limiting functionality -- which is setting limits on what we do. We do not want that, we want to make things easier.

Also, this limiting really amounts to re-arranging the costs. It is transferring the costs of future change into costs of current activity. But instead of paying those moved costs by doing *more work* now, they are paid by having *less functionality* now. Is that not contradictory to one of the principles of agile (or at least XP)? You do not try to predict the future, you just do only what you need now.

Corey Reid

The problem with the "code is inventory" idea is the same problem as the "waterfall" project process, and also the Lean way thinking -- these are all manufacturing-world models being applied to a process (software development) that has very little to do with manufacturing.

Models based on manufacturing are always going to be flawed. Software development is a design process, not a manufacturing one, and so the question of "inventory" is a meaningless one.

Greg Vaughn

It's an old article that I was just recently made aware of, but Alistair Cockburn has spent some time with this metaphor: http://alistair.cockburn.us/What+engineering+has+in+common+with+manufacturing+and+why+it+matters

I really like his concept of "unvalidated decisions" as the items in inventory.

J. B. Rainsberger

Bas Vodde and I spent a month working with different teams in the same company last year. When we met, we'd brag to each other about how much code we deleted. It's an obvious sign of improvement.


Yet another lesson one can learn from evolution. Features that are not important anymore are removed fairly quickly. On several occasions breeding has resulted in the loss of some features as the process was focused on other things to be. This can have a negative impact: Understanding which features are those you want to keep and which have to die is pretty vital.

As to the deleted code: There is always the Source Control (DNA)

Why comparisons to manufacturing should fail would have to be explained to me. Software making isn't just a pure thought process. There is a result, compiled software that does things, can be distributed and shows resistance to change. There are constraints, not only in requirements, but in hardware and infrastructure. It is not a pile of drawings, diagrams and documents or recordings of narrations describing patterns that would solve a problem.


Brilliant! Many great comments, although some still don't realise, that code (in the strict sense) is actually a liability.
I think the confusion stems from the fact, that you typically write code for some benefits. The features and new options you have gained by writing the code are the real assets.
Code was required to obtain them, but itself is only burden and maintaining it costs. It is pure liability. Could I get these benefits without it, I wouldn't think twice. Here we go to the core of the problem: many useful things just cannot be achieved without writing some code. Then I can only try hard to write it in a maintainable fashion and constantly keep it in a good shape. That will at least assure me, that I'm not paying too much for the features I gained. But again, it is a cost to factor code in an optimal way. And even then the code costs - at least the time required to read it. So when its relative value is not that high, I prefer to delete it.

One thing, that particularly costs in code's maintainance is that you have to update it whenever one of its dependencies change. The fact, that code has dependencies additionally limits the overall flexibility of the codebase. Those dependencies cannot be freely modified to not break their clients.

To sum up, 'if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent"' (Dijkstra)

Roger Pate

It would seem that perfection is attained not when there is nothing left to
add, but when there is nothing left to take away.

— Antoine de Saint-Exupéry

Alex Skorulis

I like a lot of my old code. Maybe it's not perfect but it works even if I can't remember how. If someone came along and deleted it and told me to rewrite it I would basically respond that I don't know how. I once upon a time learned how the thing worked and that knowledge has since become irrelevant. If I ever needed to understand it again I had the code to jog my memory. Now that it's gone I'm starting from scratch with no guarantee that the next version will be any better.

The comments to this entry are closed.