DevOps Zone is brought to you in partnership with:

I am an experienced software development manager, project manager and CTO focused on hard problems in software development and maintenance, software quality and security. For the last 15 years I have been managing teams building electronic trading platforms for stock exchanges and investment banks around the world. My special interest is how small teams can be most effective at building real software: high-quality, secure systems at the extreme limits of reliability, performance, and adaptability. Jim is a DZone MVB and is not an employee of DZone and has posted 100 posts at DZone. You can read more from them at their website. View Full User Profile

Source Code is an Asset, Not a Liability

  • submit to reddit
Some people have tried to argue that source code is a liability, not an asset. Apparently this “is now widely accepted” and...

“this is a very strong idea that has a lot of impact across the IT industry and in the way developers view and perform their day-to-day work”.


The argument, as far as I can follow it, is that while engineers are paid to help design and build bridges and power plants, as developers we’re paid to “deliver business value”, and…

“Source code is merely the necessary evil that’s required to create value”

Source code, the software that we create, is only a means to and end. The software itself has no value, or worse it has negative value, because it creates a drag on your ability to innovate and move forward. The more code that you have, the higher your maintenance costs will be, therefore…

“… the best code of all is the code that's never written.”

Michael Feathers, who has a lot of smart things to say about source code, joined in on this discussion. In The Carrying-Cost of Code he says that

“code is inventory. It is stuff lying around and it has substantial cost of ownership. It might do us good to consider what we can do to minimize it.”

He goes so far as to suggest a goofy thought experiment where “every line of code written disappears exactly three months after it is written”. The point of this would be to get developers and the business to understand that the “costs of carrying code are real, but no one accounts for them”.

Feathers reinforces the valid points about the drag that unmaintained or poorly maintained legacy code has on companies. Writing less code to solve a problem is a good thing – it’s (usually) more efficient and (usually) costs less to maintain a smaller code base. And yes there is a necessary cost to maintaining software and working with existing software and changing it.

But none of this changes the fact that software is an asset

If you build and operate a power plant or a bridge, you have to maintain it – just like software. And like a bridge or a power plant, a newer, more modern, better-designed, more efficient and simpler asset is better than a big, old, complicated, expensive-to-maintain one.

The “software is a liability” argument seems to be that it’s not the software that’s the asset, it’s the “features and options” – the capabilities that the software provides. This is like saying that it’s not the power plant (which a company spent millions of dollars to design and engineer) that’s a valuable asset to a company, it’s the energy that it generates. It’s not the bridge – it’s the ability to drive over water. It’s not the airplane, it’s the ability to fly.

Pretending that software has no value in itself is silly. Try explaining this to accountants (don’t depreciate the airplane, depreciate the ability to fly!) and IP lawyers and to investors who buy software companies for their IP. They all understand that software and the ideas embodied in it are valuable and need to be treated as assets. The ideas themselves are only worth so much, even if they’re patented. But the ideas realized in software, actualized and proven and ready to be used or (better) already being used – that’s where the real value is. And this is the value that needs to be maintained and preserved.

Software is more valuable than other assets

The important difference between software and other assets is that software is much more plastic than other engineering work. Software is “soft” – it can be changed easily and inexpensively and quickly. This makes software more strategically valuable than “hard” assets like a building because software can be continuously adapted and renewed in response to changing situations, and transformed to create new business opportunities.

Software has to be changed to stay useful. The problem is NOT that we HAVE TO maintain software and change it to do things that it was never intended to do, to work in ways that it was never designed to, to do things that we couldn’t imagine a few years ago. This is the opportunity that software gives us – that we CAN do this. This is why Software is Eating the World.

Published at DZone with permission of Jim Bird, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jamie Goodfellow replied on Fri, 2012/02/03 - 9:02am

Software is an assert, Source Code is a liability. There's a difference between the two. Developers should do their best to use libraries (open source or otherwise) as much as possible, rather than re-invent the wheel in their own code. This way the cost of maintaining and improving that code falls to the library developer.

Arnaud Des_vosges replied on Fri, 2012/02/03 - 10:23am in response to: Jamie Goodfellow


" Software is an assert, Source Code is a liability ..."

I agree  that you must not re-invent the wheel, but that's not a good reason to say that you should not write code and just reuse existing libraries.

This specific code source you have to write, it's really an asset. It can make your product better than products of your competitors. 

(And writting source code also includes calling existing libraries.) 

Jamie Goodfellow replied on Fri, 2012/02/03 - 2:35pm

I suppose it depends on what the product you're producing is. If your business is writing libraries for programmers to use, your Source Code is your asset. If another library company duplicates your work, that's competition, not an opportunity to reduce your code. If your product is software for people to use, I would say that the specific code you have to write and maintain to accomplish your software requirements are the cost of doing business. You want to keep this to a minimum, knowing, of course, that there will have to be _some_ if you are to make a unique product to market. And minimum is relative, chances are you'll have to write a lot of it. But if you get a chance to drop some of your own code in favour of a library that accomplishes the same thing, it's cost-effective to do so. In that way, Source Code is treated as a liability.

Arnaud Des_vosges replied on Sat, 2012/02/04 - 5:03am

So "do it yourself" only if it's something unique/better or if you can deliver a similar feature at a smaller cost than competitors. (I don't think there is a real difference between libraries and end-user softwares.)

Not a big surprise and probably not specific to software industry and source code.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.