Source Code is an Asset, Not a Liability
The DevOps Zone is
presented by DZone with partners including ThoughtWorks Studios and UrbanCode to bring you the most interesting and
relevant content on the DevOps movement. See today's top DevOps content and be sure to check out ThoughtWorks Studio's Continuous Delivery Whitepapers and UrbanCode's Webinars.
Some people have tried to argue that source code is a liability, not an asset. Apparently this “is now widely accepted” and...
Really?
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, 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…
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
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.
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.
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.
Source: http://swreflections.blogspot.com/2012/02/source-code-is-asset-not-liability.html
“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”.
Really?
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.
Source: http://swreflections.blogspot.com/2012/02/source-code-is-asset-not-liability.html
Tags:
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.)
ThoughtWorks Studios and UrbanCode, the sponsors of the DevOps Zone, are champions of the DevOps movement. Their deployment tooling solutions focus on the entire software development lifecycle, involving all parts of an organization, which helps facilitate a migration to the DevOps philosophy.





Comments
Jamie Goodfellow replied on Fri, 2012/02/03 - 9:02am
Arnaud Des_vosges replied on Fri, 2012/02/03 - 10:23am
in response to: boogle
" 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
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.