Someone asked me today about the value of a piece of software and how we go about measuring that. Here’s my reply: Software is no different from anything else: it’s only worth what you can sell it for.

As such, software has no intrinsic value — the world doesn’t need more software just for the sake of it. We need software that solves problems, opens opportunities and in other ways enhances our lives. The subtext was also, well, how do we measure software? Again, most programmers realise that measuring lines-of-code or functional complexity contributes nothing to the value equation. In fact, if you do insist on measuring LOC then this is really amount measuring the ‘cost’ side of the equation (not only the cost of creating that code but also for maintaining it).

As an example, I wrote phone2post which enabled a team traversing the Arctic circle to use their satellite phone to record voice messages which were automatically posted to a blog, mailed out to subscribers, family members, twitter etc. It was a trivial piece of code (~50-70 lines of code). In contrast, I’ve worked on a product with ~20 engineers, 300,000 lines of Java code and about 4yrs of development. It was canned because no one ever bought it. Which one held the most value?

My point: the size, or even the complexity, of the code tells you nothing about its value

Software is like a tree. Putting aside the non-economic value of trees such as personal utility or aesthetics (which software also has), a tree can be used for different purposes. It can be sold as firewood and kindling, or as timber for a house, or as the raw materials for a one-off designer chair sold for millions. But however you look at it, the value of that tree cannot be divorced from the business using it. In short, valuing software is really about valuing the business opportunities that it enables.