Badly Programmed Apps Costing IT More

Cast Software's analysis of 365 million lines of code shows hurry-up development passes along problems to enterprise IT.

Charles Babcock, Editor at Large, Cloud

December 9, 2011

5 Min Read

10 Massive Security Breaches

10 Massive Security Breaches

(click image for larger view)
Slideshow: 10 Massive Security Breaches

A second annual study of the quality of enterprise IT applications found an ongoing set of issues buried in many applications. Cast Software analyzed 745 enterprise applications for their structural quality and found a rising cost for the problems buried in the code upon deployment.

Cast is one of the few parties to put a dollar cost to the "violations" of good structural design that it finds. The cost to fix each violation runs $3.61 per line of code in the application. The cost last year was estimated at $2.82, according Bill Curtis, senior vice president and chief scientist at Cast, in an interview. The two studies examined different mixes of applications, with many more applications included in the second, making it difficult to explain the increase, Curtis noted. The estimate is based on a $75-an-hour programmer expense and fixes taking one hour each, a "conservative" estimate, he said.

The Cast study, unlike other inspections that are looking at business function or security, is about sound code structure. Structural quality has nothing to do with whether software performs the functions it was designed for; rather, it’s about whether the code performs them efficiently and robustly with both security and ease of maintenance.

The Cast study is based on 365 million lines of code--in applications from 160 companies--that the firm keeps in its AppMarq repository. Because it is based on real-world apps, the Cast Report on Application Software Health is likely to find a permanent place in the current DevOps debate. Programmers and operations managers are divided over whether software development efforts do enough to ensure that the code will run without mishap in production. Developers are sometimes accused of having too little operational experience to foresee how their code will perform after deployment.

[ Want to learn more about the Agile/DevOps debate? See Where Agile Development Fails: IT Operations . ]

The 745 applications reviewed by Cast's automated analysis included 288 Java applications--or 39% of the total, a higher share of the mix than last year. The study found "Java still had the lowest performance scores. That was fairly clear this year," compared to the previous study, Curtis said.

When Java first came out, it was described as an innovative language that couldn't run very fast. Over the years, Sun and Java Community Process participants improved its performance by reducing the pauses it took for garbage collection and through other tricks. But it still ranks the lowest of the 20 languages covered by the study, including C, C++, and Cobol.

Another finding that emerged in last year's study and was confirmed in this year's: Government applications are harder to maintain than enterprise applications. "Gartner says the government has much higher maintenance costs" than different industries within the private sector, said Curtis.

He attributed the higher costs to the government's need to accept the lowest-cost bidder on projects. The winning bidder then produces code that will be maintained by another party in a separate contract, leading the original contractor to expend less effort on maintenance. Government applications in whatever language, however, had "much more complex components" than the private sector, he said.

Given the government's need to rely on lowest-bid contractors, the applications it gets through contract consultants tend to be built as quickly as possible, with the contract to maintain them going to someone else, points out Curtis.

The 2011 study affirmed last year's study in finding Cobol applications are more secure than those built from other languages. Curtis noted that Cobol apps typically run on mainframes, which are inherently more secure than the Unix, x86 server, and Windows environments. But he also noted that Cobol applications are also "more complex, with components that may run up to 600 lines." That makes them harder to change, while the average component of Java and other languages is between 20 and 50 lines.

Java in particular is used in modular applications, where modules may be modified without affecting other parts of the application, an approach that "helps get control of complexity," Curtis noted.

Cast used its automatic code analysis platform to examine the 745 applications, noting any departure from recommended best practices in structural design and implementation. The "violations" that it finds are not necessarily going to stop an application from running. Rather, they might cause it to run less efficiently or be more susceptible to interruption than good practices would say it should be.

Examples of what the Cast engine looks for include:

--Buffer overflows, where programmers have left a buffer that is larger than the minimum information needed to be input by an application user--and hackers can exploit the extra space.

--SQL injection, where programmers have left an opening for a hacker to use an SQL statement instead of the expected input, resulting in an illegitimate call to the database.

--A database call inside a program loop, that must access a large amount of data each time the loop is executed.

--Failure-to-use indices in a database application, resulting in the need to inspect all the data in the database.

Structural violations "are coding practices that don't control the behavior of the application in appropriate ways. They're often used by people who do not have training in computer science," he said.

The defects also are often recognized and targeted for future review and repair as development teams hurry toward project deadlines. Unfortunately, said Curtis, the opportunity to revisit the code and clear up problem areas never comes. The poor programming practices then go into production and amount to a liability, which can be measured by a metric--the "technical debt". A program with 300,000 problematic lines of code has a technical debt of over $1 million in expenses that will be run up as programmers revisit the code and try to clear up issues or as programmers scramble to repair the code after an outage, Curtis said.

Read our report on how to guard your systems from a SQL attack. Download the report now. (Free registration required.)

About the Author(s)

Charles Babcock

Editor at Large, Cloud

Charles Babcock is an editor-at-large for InformationWeek and author of Management Strategies for the Cloud Revolution, a McGraw-Hill book. He is the former editor-in-chief of Digital News, former software editor of Computerworld and former technology editor of Interactive Week. He is a graduate of Syracuse University where he obtained a bachelor's degree in journalism. He joined the publication in 2003.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights