Software As Liability

Code is a liability.

What the code does for you is an asset.

Producing more code is not always a gain. Code is expensive to test and maintain, so if the same work can be done with less code that is a plus. Don't comment out dead code, just delete it. Commented out code goes stale and useless very fast, so you may as well delete it sooner rather than later, to loose the clutter. Keep good backups to make it easier.

Perhaps only LegacyCode is a liability. Once the code has been factored so that it can be easily maintained and reused, then it becomes an asset.

It's only an asset if it does something that is useful to you, regardless of how easy it is to maintain. A well-factored, easily maintainable program that solves the wrong problem, may cost more to hold on to than it's worth. Even if you expend no effort to maintain it, the cognitive load of an attractive nuisance is also a cost.

Related pages: XpCourageValue

Inspired by but otherwise unrelated to: SoftwareAsCapital

Do we know how to measure the lifetime CostOfLineOfCode?


James Shore has proposed a metric for measuring technical debt: lines of code.

http://jamesshore.com/Blog/An-Approximate-Measure-of-Technical-Debt.html

Also:

"Measuring programming progress by lines of code is like measuring aircraft building progress by weight."

  -- Bill Gates

{Windows is certainly a weighty OS.}


Re: "Don't comment out dead code, just delete it."

I have to disagree as an absolute. One should weigh the trade-offs using estimated cost-benefit analysis and probability path trees, or something approximately equivalent.

Another approach is to mark the commented-out code with a date. Then every few years review all marked code and delete the marked code still not used after 3 or so years. But first paste it into a "snippet archive". I've seen hard-to-build features come back from the dead. -t

"Snippet archive"? Dude, get yourself a VersionControl system. Then just delete the code.

Ideally you want something which tracks the changes in code documentation, and presented old versions in a useful way, to make it easier to find and dig out old functionality. Obviously, that only really works at the function level and above (chunks of code inside a function are harder to label and re-use). I don't think I've heard of such a tool in practice, and it would be moderately tricky to make the UI helpful, especially since it would really need to inject its old-version links into the current documentation.


TheGoal, AnalogyBetweenProgrammingAndManufacturing (? code is to "what code does for you" as inventory is to throughput ?)


By comparing technical debt to credit card debt and quantifying the amount of time a programmer spends paying down technical debt (a subjective measure) it is possible to QuantifyTechnicalDebt.


EditText of this page (last edited December 17, 2013) or FindPage with title or text search