Poor Software Quality Costs Trillions. Yes, Trillions.

By Perry Cohen

Associate Editor

Embedded Computing Design

February 25, 2021

Story

Poor Software Quality Costs Trillions. Yes, Trillions.
(Image courtesy of The Cost of Poor Software Quality in the U.S.: A 2020 Report)

We all know that flawed software can be expensive. But just how expensive?

According to “The Cost of Poor Software Quality in the U.S.: A 2020 Report,” that cost was more than $2 trillion in 2020. And that was just in the U.S. alone.

The report, produced by the Consortium for Information & Software Quality, or CISQ, is broken into three categories:

  • Unsuccessful software projects, which accounted for $260 billion

  • Poor software quality in legacy systems, another $520 billion

  • And operational software failures - $1.56 trillion (up from $1.275 trillion in 2018)

(Image courtesy of The Cost of Poor Software Quality in the U.S.: A 2020 Report)

We may be able to deal with the $260 billion in unsuccessful software projects. That’s just general risk. But poor software quality in legacy systems and operational software failures; these are serious issues even when they don’t affect embedded systems that could potentially cause damage, injury, or death.

How is it possible that software quality is falling so short across so many different dimensions?

Herb Krasner, the author of the report and a CISQ Advisory Board Member, compiled data from 88 different sources as background for the report. He said that software is growing at a rate of approximately 111 billion lines of code each year, and that even the best software engineers commit an average of 25 bugs per thousand lines of code.

So, more software, more flaws.

It’s that and, “cost and speed to market,” Krasner explained.

“This is one of the things that's wrong with the Agile/DevOps world. What they've been pushing is a continuous cycle of getting releases out the door without necessarily paying good attention to quality, so perhaps there's more suspicious software being developed and produced even today than there was in the past.”

“Most of the Agile development teams, they focus on features. They don't necessarily leave the appropriate amount of time for fixing the bugs that pop-up during that sprint. In fact, they often defer those to a later sprint and they may or may not get around to it.”

So, what can be done to reverse the course of costly, faulty software?

Developers can start by trying to catch or prevent defects earlier in the development stage, which is the obvious solution. But in order to do this, they need to start slowing down development to catch the bugs, which works at cross-purposes with the Agile/DevOps practice.

This is where DevQualOps comes in. It’s similar to DevOps, a continuous loop of agile development coupled with the idea of continuous delivery and continuous or frequent releases. However, DevQualOps addresses the quality of the engineering activity.

(Image courtesy of The Cost of Poor Software Quality in the U.S.: A 2020 Report)

Krasner added, “In the DevQualOps model there are specific quality gates at the end of each of the phases of requirements, design, development, and testing. So, there's an explicit quality check that must go in along with these ideas of explicit quality engineering.”

Products don’t need to be rushed, they need to come in waves.

Developers need the time to implement quality control practices, identify bugs, and fix bugs. Further, organizations need to balance their time to market goals with the simple fact that software remediation becomes more and more costly the further you get into the development and product lifecycle.

 “Here is a big problem: It's mostly unseen and unquantified and perhaps even undiscovered within most organizations,” Krasner said. “What we see is the underlying trend that the cost of finding and fixing defects in reaction to those failures has gone up considerably.”

The DevQualOps model and companies like OverOps who specialize in DevQualOps solutions, could have a positive effect on the current state of software quality, requirements, and objectives.

Krasner finished by stating, “There's this whole idea of what's called ‘shift-left quality,’ where we try to make it the point that it actually costs less to develop good quality software than it does to develop poor quality software and get it out the door quick.”

Despite the report focusing on faulty software, Krasner did say that there’s plenty of exceptional software in the world.

Perry Cohen, associate editor for Embedded Computing Design, is responsible for web content editing and creation, podcast production, and social media efforts. Perry has been published on both local and national news platforms including KTAR.com (Phoenix), ArizonaSports.com (Phoenix), AZFamily.com, Cronkite News, and MLB/MiLB among others. Perry received a BA in Journalism from the Walter Cronkite School of Journalism and Mass Communications at Arizona State university.

More from Perry