If your organization has an application with approximately 374,000 lines of code, you can expect a technical debt—the cost to fix problems that remain in an application once it is operational—of about US$1 million, according to the first CAST Worldwide Application Software Quality Study, which was released yesterday.
CAST, a provider of software analysis and measurement solutions, arrived at that figure using $75 as the average hourly wage of a developer and assuming each problem takes an hour to fix. The average maintenance cost per line of code was $2.82, the study found.
An application with 374,000 lines of code was considered the average in this study after 288 IT applications from 75 organizations (ranging from energy, financial, government and telecommunication sectors) were statically analyzed for structural quality. The results of the analyses were captured in Appmarq, a structural quality-benchmarking repository maintained by CAST.
According to the study, structural quality was defined as “the non-functional quality of the software application that describes how well the software is engineered from a source code perspective. It is also often referred to as the technical or internal quality of the software application.” In this study, quality was focused on an application’s security, performance, robustness and changeability characteristics. The structural quality characteristics were also scored on a scale of one (high risk) to four (low risk).
Aside from concluding an average application’s “technical debt,” the study delved deeper into “quality” of programming languages, namely C/C++, COBOL, Java, .NET and Oracle 4GL. COBOL, due to its age and use mainly in mainframes that run in highly regulated environments, was found to score the highest in security, said Bill Curtis, CAST’s chief scientist and senior vice president of the CAST Center for Quantitative Research.
Financial and insurance sectors scored well in this category due to their heavy reliance on mainframe applications, which reduce exposure to security problems seen in a lot of Web applications, he added.
.NET applications received some of the lowest security scores, suggesting that the IT community’s attention to security may be primarily driven by compliance regulations, which are not as intensive as regulations for COBOL, which is used in more secure applications for banks and such.
After looking at things in the structure that are known to affect performance while data grows (such as incorrect indexing), Curtis said, Java EE applications performed most poorly, with .NET applications almost as poor. The performance of applications written in other languages skewed more positively.
CAST hypothesizes the cause of this particular trend is the availability and use of automated performance testing tools and end users complaining to development teams about slow performance, making the remediation of performance a priority over other quality problems.
Deeper analysis of the data revealed that newer, Web-facing technologies, such as Java EE and .NET, also scored lower in robustness, which are defined as “attributes that affect the stability of an application and likelihood of introducing defects when modifying it.” However, robustness revealed the most tightly clustered scores in all of the quality characteristics, and that cluster skewed toward the negative side.
Changeability, or the ease in which an application can be modified, was lowest in the government sectors. Curtis attributes this to how the government acquires applications.
“Multiple contractors working on an application over time, disincentives in contracts for building easily maintainable code, and challenging acquisition practices are potential explanations,” the study said. The government also outsources 75% of its applications, compared to 50% in the private sector, the report said.
CAST also theorized before the study that the size of any application would affect its quality. Consequently, this was found to not necessarily be true, Curtis said. Except for old mainframe applications written in COBOL, which do not encourage modularity and have a very high percentage of large and complex components, there is no impact, he added. However, modularity, or the “tightness of coupling between components,” has a direct impact on quality.
The more intertwined components are, the more difficult it is to change or modify an application. In contrast to COBOL applications, “the designs of more recent languages encourage modularity and other techniques that control the amount of complexity as applications grow larger,” the study said.
So what do these findings mean? Performance and security are at the forefronts of most developers’ minds, especially in critical applications. Less attention is paid to reducing changeability problems, creating an increase in the cost of ownership in the long run, the study said.
These findings also suggest that “the developer community is very reactive and not proactive,” Curtis said. Especially in agile environments, time needs to be built in for remediation and refactoring prior to shipping, he added. “If you don’t do something about it now and continue to write code, you’re going to continue to build technical debt.”
