A Billion Here, a Billion There

In a 2002 National Institute of Standards and Technology report entitled “The Economic Impact as Inadequate Infrastructure for Software Testing,” software defects costs nearly $60 billion annually in the United States alone. This report is often misquoted assaying that software bugs cost $60 billion but software bugs likely cost industry and consumers much more than that but we have no way of knowing since many companies downplay their failures. What the report actually says is that *poor software development processes* cost the software development industry nearly $60 billion a year in wasted effort during the software development process.

This conclusion is supported by other studies as well. In the paper, “Software Project Failures Costs Billions: Better Estimation and Planning Can Help,” author Dan Gallerith estimated the cost of software project failures to be in the range of $50 billion to $80 billion a year. These are enormous losses and they are commonplace in the software industry. And all of these losses are preventable. If we just pay attention to building software more effectively we could significantly decrease these losses.

But as much as it costs to build software, and as much as we waste by doing it so inefficiently, the real losses for many companies are yet to come. It’s estimated that 80% of the cost of software happens after the initial release.

The next time your manager complains to you about how long it’s taking o build a feature and how much that costs the company, you can tell them that for most software, the vast majority of costs are in maintaining and not developing new code.

Fixing bugs costs about half as much as all initial development, and post-release enhancements cost almost twice as much as initial development. Why does it cost so much to fix and enhance software?

The short answer is that as an industry we do not value maintainability as much as we should and so we build products that are difficult to maintain. We operate under the assumption that just getting something out the door is good enough. Yet we’re slayed by these very assumptions when the burden of our technical debt gets in the way of us releasing new product.

But it doesn’t have to be this way. When we understand the nature of change and how to accommodate change through engineering, we can build software that costs less to construct and drastically less to maintain and enhance. This is the subject of my new book Beyond the Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, in which I present specific technical practices can help us build more maintainable software and how to apply them most effectively.

I have shown teams from the top software companies on the planet how to build more effectively using these technical practices. I can attest to the fact that they work, but they don’t work automatically. They work when they are understood and used correctly.

Very few other sources delve into why these practices ae effective. And just knowing what they are without understanding why they work isn’t enough for most people to use them effectively, grasping the motivations that underlie these practices is key, and that’s what Beyond Legacy Code focuses on.

You can find out more by going to http://BeyondLegacyCode.com.