Blog

If you have been following the economics of software quality over the years, then this harsh reality may come as no surprise. Since their landmark book, The Economics of Software Quality, Capers Jones, Olivier Bonsignour and Jitendra Subramanyam, Addison-Wesley Longman, published in 2011, more attention has been given to the economic cost of poor quality software. This book provided some excellent material that can be used to help organizations understand where the quality related failure points are in the software engineering lifecycle and to attach some monetary values to the cost of these failure points.

However, that attention is not reaching enough of us in the software engineering industry. The numbers continue to paint a bleak picture.

The 2021 Consortium for Information & Software Quality (CISQTM) report estimates that poor software quality cost the United States economy over $2 trillion in 2020 due to operational software failures, poor quality legacy systems, and unsuccessful projects.

Compared to the U.S. projected Gross Domestic Product (GDP) of $20.66 trillion, or the $1.4 trillion spent on employing IT/software professionals in 2020, this number is staggering. Reference: CISQ The Cost of Poor Software Quality in the US: A 2020 Report (2021). The cost of poor software quality exceeds $2 Trillion annually just in the US alone?

Wow. Seems almost unreal at first glance. Until you dig into the numbers and you start reflecting on your own journey as a developer, quality assurance professional, project manager, architect, or any number of other roles you have had on software engineering teams over your career.

If you are honest, you have probably been on your fair share of projects where time-draining and mostly avoidable bug related activities have happened.

How much time have you witnessed within your own teams being wasted on finding bugs, writing bug reports, fixing bugs, retesting bugs, re-opening bug reports, explaining bugs in meetings/email/slack, attaching screen shots of bugs or creating videos of bugs, dealing with bad builds/bad configuration settings that wasted hours of development effort and testing?

What are the real costs of all of these activities within your organization? Have you measured them? Most people will answer no. And with that answer, the cycle continues because you can’t fix what you can’t quantify. The default position on most software project estimation teams is to not even consider the cost of poor quality. Of course, having blinders on does not mean quality problems will disappear. In fact, they will grow exponentially when ignored or not planned for.

We can do better. We need to start paying closer attention to quality up-front. We need our project managers and project sponsors to be hyper-aware that quality related issues will not just slow down our projects, they will cause them to be much more expensive.

Developing a quality strategy and having a quality vision for your products is an organizational imperative.

Provide your teams with the tools and the training they need to both eliminate creating these bugs as well as finding/fixing them as early as possible. Champion quality at the beginning and uphold its value throughout the project’s duration. It is ok to start small and measure as you go, just be sure to measure with the right metrics so you can take those next steps needed to improve incrementally.

If you need help justifying the investments, develop an ROI for quality using your specific project goals and timelines. There are a lot of resources to turn to that will help jump-start such an effort such as professional testing associations and software engineering resources (blogs, articles, academic papers). Present the ROI to the right people in your organization. If you have to (to make your case) take it to the people that control the purse strings, the technology planning board, the project management office, etc.

Don’t let bad software eat away at your projects, even as it is slowly eating away at the world.