Java apps have most flaws, Cobol is cleanest, study finds

There is a lot of badly engineered software in the world that's creating a lot of risk to businesses and organisations, and accumulating so-called 'technical debt.'

Such a legacy of problematic programming that violates good architectural and coding practices is called " technical debt ," a metaphor that is gaining broader attention.

Poor quality code, whether the result of business decisions to cut corners or weak programming skills, may be responsible for a computer system crash, a security breach, poor performance or data corruption, among other things.

Repairing each line of code has a cost, or technical debt, that accumulates.

An example of technical debt is illustrated by the Year 2000 problem, when many applications were poised to represent the millennial as 00 and interpreting it as 1900. Organisations worldwide spent untold amounts of money remediating two digit dates. Some of the applications were built by developers who knew the problem would arise eventually.

Cast Software, a maker of software quality tools that evaluate the engineering soundness of the architecture and coding of an application, analyzed the 745 applications which combined for some 365 million lines of code. The company Thursday released a report detailing the conclusions of that analysis.

Cast analyzed applications from 160 companies in nearly a dozen industries.

The analysis included searches for as many as 1,800 types of development violations in applications written in Java EE, Cobol, .Net, C, C++ and other programming languages.

Cast counted up the number of violations and then calculated the the average technical debt to repair each line of code at $3.61. That figure is based on what it would it would cost to repair each violation at $75 per hour.

In looking at specific languages, Java EE fared worst at $5.42 per line of code, while Cobol did best at $1.26.

Bill Curtis, chief scientist at Cast, said he believes Cobol did best because the code is older. Programmers "have been beating on it for 30 years" and in that time have fixed some of the most critical violations, he said.

As for Java, Curtis said he can only speculate on the problems, but said that "there are many people going into Java now that really don't have strong computer science backgrounds. We may just be seeing the fact that there is an awful lot of people writing code who aren't gurus in software engineering."

Cast's study comes amid growing interest among IT organisations in understanding the corporate implications of technical debt.

Carolyn Seaman, an associate professor of information systems at the University of Maryland, Baltimore County, and the principal investigator in a National Science Foundation-funded program on technical debt, said the increasing attention is partly because "the metaphor just resonates with people."

There has long been research on the technical debt problem, "but this metaphor now makes it easier for researchers to describe their work in a way that makes it relevant for practitioners," she said.

"One obstacle to improving software quality has been the uncertainty around what development techniques and approaches actually result in higher quality," said Seaman.

Gartner last year chimed in on this topic, redefining the term as "IT debt." The IT research firm puts the worldwide cost of deferred maintenance in 2010 at $500 billion and rising to a trillion dollars in a few years.

It remains to be seen how efforts to affix a certain cost to technical debt can be used to provide a clear guide to business risks. But businesses are starting to pay more attention to the issue, said John Heintz, a technical consultant at Cutter Consortium.

Heintz said he has begun to see technical debt being raised as a due diligence issue in mergers and acquisitions, and increasing awareness of it is influencing software development practices.

Putting more attention on technical debt doesn't mean that developers won't still cut corners to speed development, said Heintz.

"Sometimes it is appropriate and necessary to cut corners, but it is never appropriate to forget that you cut them and ignore the fact," said Heintz.

The Software Engineering Institute at Carnegie Mellon Universities, a federally funded research center sponsored by the U.S. Department of Defense, started working on the technical debt issue about two years ago and has been organising workshops on the issue, according to Ipek Ozkaya, a senior member of the technical staff.

"There is increasing interest in this area because people want to get to the foundations of it," said Ozkaya.

Beyond some code metrics about how to illustrate technical debt, Ozkaya said there is a lack of guidance "about how to pay it (technical debt) back and how to know when you even have to pay it back, and how to map it to your changing requirements."