One of the biggest fallacies of our time is that software is indeed “soft”. For the last thirty years I have continually heard that it’s hardware that costs money, that it’s hardware that adds value, that it’s hardware that the customer buys. I once worked in a development group that had 30 people working on hardware and 120 people working on software and yet the organisation’s whole attitude was that they developed and sold hardware. They priced their product in terms of the hardware features and options that they offered. And yet the vast majority of their development costs were software.
After a year or so working for these guys I had a late evening discussion with the Boss where I tried to convince him that he should price his product based on its software features/value, that he should just give the hardware away for free, at least metaphorically speaking. He told me that although he appreciated the point, the Big Issue was that the hardware costs appeared on his Bill of Materials and software development costs were capitalised and depreciated, and thus were never directly associated with the cost of sales. The cost price was consequently driven by hardware only and therefore the product was priced in terms of its hardware features/value.
This attitude is endemic across the whole high tech systems industry. The result is that very few businesses are aware of what their software has actually cost them to develop over the course of time and how much value the software truly represents. Various studies show that the cost of developing a line of industrial software in the western world falls in the range EUR 20,- to EUR 40,- per delivered line of code. A typical modern day medical X-Ray system may have 15 million lines of code, development cost EUR 300M – EUR 600M. Development effort around 3125 man years. This represents such a huge investment that most organizations can only afford to reengineer 1% – 5% of their code base every year. In other words, in the course of time their software has turned into a horribly “fixed” asset.
Technical debt in software further adds to this problem. Technical debt refers to the long term engineering problems that arise in software as the result of short term business decisions. It leads to software ‘rotting’ in time, becoming more difficult to maintain, update or reengineer. Technical debt equates to work that needs to be done on a software code base just to stand still and therefore represents costs that need to be incurred that do not result in an increased value of the end product. Technical debt is the enemy of software driven innovation because it has the potential to slow down progress to a crawl.
In short, there’s nothing soft or benign about software. Conventionally developed, it is extremely hard and expensive to change quickly. The combination of a large legacy code base and accumulated technical debt poses concrete problems for businesses dependent on innovation. Successful software driven innovation requires the adoption of a strategic long term, leadership driven approach to software engineering that focuses on keeping software from turning into concrete.