Source Code Is A Liability, Not An Asset


Update: this blog is no longer active. For new posts and RSS subscriptions, please go to http://saintgimp.org.

In my previous job, I once scribbled something on a window that caused a bit of head-scratching by people who read it:

“Source code is a liability, not an asset!”

Of course, the idea isn’t original with me.  I got it from (I think) Tim Ottinger and Alan Cooper said it earlier, and for all I know someone else said it even earlier.

(As an aside, one of the painful realizations that have dawned on me as a new blogger is that I’m not very likely to invent and blog about a truly unique idea.  I’m very thankful that I’m standing on the shoulders of so many giants, but the bar for originality is, um . . . rather high.  That’s ok.  I can still restate other people’s ideas in my own terms, within my own context, and I think that adds value to the community.)

Anyway – source code is a liability.  That doesn’t make much sense at first.  Don’t we spend our entire professional careers designing, writing, and testing code?  That’s what we do, right?  Well, no.  What we actually do is deliver business value, or solutions to real-world problems, or however you want to state it.  That’s why companies employ software developers.  Source code is merely the necessary evil that’s required to create value.  With few exceptions, source code itself is not a valuable commodity.

Source code is akin to financial debt.  Suppose you want to buy a house to live in.  Most people don’t have the financial wherewithal to pay cash for a house, so you take out a mortgage instead.  The mortgage is the instrument that allows you to have a house to live in.  But the mortgage itself is not a great thing to have.  It’s a liability.  You have to pay interest on your debt every month.  You always want your mortgage to be as small as possible while still allowing you to buy a house that meets your needs.

And as we’ve seen in the news recently, if you don’t do some careful thinking about the terms and implications of your mortgage before you buy a house, you can wind up in a load of trouble.  It’s possible to end up underwater in a situation where your debt is actually bigger than your house is worth.

So too in software development.  We start with a value proposal; something we want to accomplish.  Writing code is the means we use to realize that value.  However, the code itself is not intrinsically valuable except as tool to accomplish some goal.  Meanwhile, code has ongoing costs.  You have to understand it, you have to maintain it, you have to adapt it to new goals over time.  The more code you have, the larger those ongoing costs will be.  It’s in our best interest to have as little source code as possible while still being able to accomplish our business goals.

This has implications for the way we do metrics and the way we design software.  For example, LOC (lines of code) numbers should never be taken as an asset measurement.  “This week our team wrote 10k LOC!  We’re very productive!”  Well, no, that number doesn’t say anything about whether you’re being productive, any more than saying, “This week we took on $10,000 in new debt!” indicates whether you’re being productive.  The question is entirely, “What did you do with that LOC/debt?”

Taking the long term view, probably one of the most productive statements a team can make is, “This week we removed 10K LOC while preserving all existing functionality!”  That doesn’t sound very sexy on the face of it but it contributes to your organization’s long-term health in the same way as reducing your financial debt.

Software designs that favor less code tend to be better designs that give you a higher return on your investment.  You can take that too far, certainly; well-written, maintainable code is often more verbose than dense, impenetrable code, but you should always favor maintainability.  The difference between the two is relatively minor compared to decisions about whether to use a third-party library or write your own implementation, or whether to refactor existing code to meet changing requirements vs. simply piling your new stuff on top of the old stuff.

(Another aside – ever notice how companies will happily spend multiple months of an employee’s time, at a true cost of at least $10,000 a month, counting benefits, office space, and the like, in order to avoid paying $1000 or even $500 to license a third-party software package that does the same thing?)

I’m looking right now at a project that’s been passed through the hands of several different owners over several years.  It has 134K LOC checked in to source control, and it could likely be implemented in about 10% of that, maybe 5%, using common, industry-standard libraries available today.  Granted, many of those libraries didn’t exist when this project was first started, but the code wasn’t refactored to keep up with the times.  In some respects, it’s underwater now in terms of its debt-to-value ratio.

When you’re faced with a project like that, one of the most beneficial things you can do is to start paying down the debt.  Bust out your delete key and start whacking.  Until you do, that debt is going to paralyze any other efforts to deliver new value to your customers.  Of course, it’s got to be done very carefully, especially if you don’t have the safety net of unit or automated acceptance tests (and in situations like this, you usually don’t).  Nonetheless, it’s absolutely critical that you get yourself above water as soon as possible.

Comments (4)

  1. Jamie Dobson says:

    I am not sure that you are fully correct here.  But, I will warn you, I am no accountant, so, will you indulge me?

    An asset, if I cast my mind back to A-Levels accounts, is a thing, a piece of capital – hence the expression ‘capitalism’ – that is used to generate wealth.  A big machine, let’s say a boat for a fishing captain (I am from a fishing town, Hull), is a piece of capital, an asset.  A perfect asset would never deprecate, which is cool.  A boat will, and it will require maintenance.  The assets, the boat, are absolutely essential to generate a profit.

    Now, if you look at the capital investment of, let’s say, generating a report for a client.  The money would go on a computer, a spread sheet license, and, for arguments sake, a small VB program to do the ‘essential calculations’.  Those calculations may be based on a cool model the company created, that’s an asset too.  Each one of these ‘things’ are essential to generating profit.  Therefore, they are assets.  Each one will deprecate at different rates.  The software, when badly done, will deprecate badly.  Good software, mind, can last for a looooooooong time.

    So, I think the software you describe is a very badly deprecating asset.  This is very much like the tube lines in London… they require a shed load money, but they are assets.  Now, if you wanna get all Lean on the matter, you would say that the tube/your software, are type-2 muda, and we need to get them into line, i.e. change them into type-1 muda.

    Maybe the metaphor you are looking at are the unfinished sky scrapers of the last bubble.  They are like bad software.  They need maintaining, or pulling down, and they represent an investment that never paid itself back.  They are the physical manifestation of stupidity and greed.

    Now, terms aside, the real fact of the matter is that bad software will erode your bottom line, your net profit.  It’s like that Monty Python skit where they take the cost of the machine that goes ping from the annual budget and put it on the monthly budget.  The net result is the same – whether we call it an asset or a liability – the machine that goes ping costs someone something.  If you message was meant to be that bad software costs, then well done, you nailed it.

    Finally, you could cause some really interesting discussion by asking your boss to spend money on a liability.  If software is a liability, then we’d never write it.  No, software development – like sky scraper development – is risky.  But that’s another blog, I guess.

    Thanks, Jamie.

  2. SaintGimp says:

    Thanks for the feedback!

    The problem with analogies is that they tend to break down if you push them too far.  I’m not an accountant either, and maybe the word "liability" isn’t technically correct in this case.  But what I was trying to capture is the idea that writing more lines of code does not automatically equal creating more value.  Sometimes removing lines of code is the most valuable thing you can do.

    Why would I throw away perfectly good code that I’ve already paid for?  This is where thinking of code as an asset isn’t a perfect analogy either.  If I’ve spent a ton of money on a huge fishing boat, I’m not likely to start chopping off pieces of it and tossing them away.  If for some reason I decide I need a smaller boat, I can sell my big boat, buy a smaller one, and have cash left over.  But with software, there’s rarely any intrinsic value to the lines of code I’ve written.  There’s intrinsic value in what the software *does*, but that’s a different thing.  The lines of code are just a sunk cost that I can never recover so if I discover some way to get rid of some of them, I should do so.

    I’m way out of my area of expertise here but maybe the best accounting analogy would be to say that software is an asset who’s book value instantly goes to zero as soon as you pay for it, but still generates fixed costs.  

    It’s not just that bad software costs – *all* software costs.  Every line of code you write will continue to generate an ongoing maintenance cost for as long as it exists.  It’s not as obvious as a machine breaking down and needing to be fixed; software doesn’t wear out.  But it generates maintenance costs in the time spent to understand it later and in the inertia you have to overcome when you want to change it.  Well-written code can minimize those costs, certainly.  But the best code of all is the code that’s never written.

  3. Cheers. says:

    If the source code is used by the company to create revenue then it is an asset of the company.

  4. DLed says:

    I'd add, "source code is a liability, and green acceptance tests are assets". To @Cheers, it's not _the_ source code that creates value by itself, it's the acceptance of its effect by the customer that generates revenue.