Welcome

Dear Reader,

After all these years in publishing, it is really hard to grab my attention with a random headline, but I have to admit this one caught my eye: "Poor Software Quality Costs the US $2.4 Trillion." At first I thought it was a typo. (I was thinking maybe it should be "Billion" – I had no illusions that it was going to be "Million.") But with further reading, it appears that "Trillion" really was what they had in mind.

All the articles that appeared in the press with some variation of this headline pointed to a report by the Consortium for Information on Software Quality (CISQ) [1]. CISQ is an organization founded by the Object Management Group (OMG) standards development organization and the Software Engineering Institute at Carnegie Mellon University. Partners include security organizations and consultants, including MITRE and Gartner Group.

The report lists three main reasons for this astronomical loss:

• Cybercrime
• Software supply chain problems with underlying third-party components
• Technical debt

Cybercrime receives the most attention, but, according to the report, it is actually the least costly of the three categories. Much of the discussion of the supply chain problems points a finger at open source software. In this case, though, the argument doesn't seem to be so much about the fact that the code is open source as the fact that the same few free components are used so extensively. According to the report, "A medium-sized application (less than 1 million lines of code) carries 200 to 300 third-party components on average." Some of the most popular open source components are built into thousands of applications, so if a problem is found in one of these components, it is echoed thousands of times. Also, as the report points out, the free availability of open source components means the programmers oversee a smaller percentage of the code in the final application and a larger percent of the code comes from sources beyond the programmer's control. Many companies simply don't rise to the challenge of keeping up with all those moving parts. The report quotes a Black Duck study that found that 99 percent of audited codebases contained open source components, and 81 percent of those components were out of date.

The discussion of technical debt was perhaps the least familiar for the average user. Technical debt is a concept from the field of economics that doesn't receive a lot of attention in the technology industry. Wikipedia refers to technical debt as "…the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer." The idea is that, by applying a shortcut or quick fix to a problem (or by ignoring a problem, which also happens), you incur a debt that you will have to pay back in the future. The degree to which the problem will be more difficult to fix later is a form of "interest" on that debt.

Economists and venture capitalists need a concept like technical debt to estimate the value of a company. Suppose you have two companies that start with the same software. Company A has a team of developers continuously maintaining and updating the code, which is good development practice, but it also exacts a cost in overhead. Company B doesn't bother with maintaining this level of investment. They might have one coder applying security fixes, but the underlying problems accumulate. Company B minimizes overhead, and might even claim to have a greater "profit" for the year, but all they are really doing is deferring the expense to a later date. Technical debt is a measure of those deferred expenses.

You might be wondering why all this matters. Numbers like $2.4 trillion are intended to shock. Doesn't every industry have to plan ahead for some form of waste? Perhaps, but you can also bet that every successful company is focused on how to keep that number as low as possible. Some of the solutions offered in the report are remedies you've heard about for years: better quality standards and better tools for finding deficiencies. One of solutions is relatively new for this kind of practical discussion, though it is an ongoing dream of futurists: expanded use of AI and machine learning for software development.

Cybercrime and security issues dominate the news cycle. Other code quality concerns are discussed within academia, and to some extent, within the programming profession, but they receive far less attention in the press. The real value of documents like the CISQ report is to bring these issues to the surface. Perhaps the open source community really does need to spend a little more time considering what else can be done to support those core components – including educating developers on keeping them up to date. And the next time you invest in a software company, don't just look at the revenue: Take some time to consider the company's commitment to their code.

Joe Casad, Editor in Chief