The software that costs the most to fix once live, revealed

A survey by software quality testing company Cast, known as appmarq , has today revealed the typical costs companies could face fixing code after software has been rolled into the live environment.

The company says the average cost of fixing software bugs after release is $2819 per thousand lines of code. Cast says the typical business application has 374,000 lines of code.

And here are Cast’s figures on the average number of problems in code, for different programming languages, that are serious enough to cause business risks.

Violations per thousand lines of code:

ABAP   – 20

Cobol  – 89

.NET    – 169

J2EE     – 463

C/C++ – 438

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

I am not a programmer, but I would expect that java and c++ would use more well tested third party and in house common libraries. So there is more complex business logic per significant line of code that is written for an application.

I've worked with Java and C/C++ and I'm not surprised these are the big ones, although I am surprised that Java code apparently has as many bugs as C/C++. When Java was invented, one of its great advantages was that it was easier to use than C/C++, so what's happened to the quality of code in the intervening years?

Java and C/C++ are seen as general purpose languages which kids learn in college, whereas ABAP and COBOL are mostly used by specialists these days i.e. people who know what they're doing, so you'd expect fewer bugs here.

Interestingly, .NET - which plays a similar role as J2EE - seems less vulnerable to bugs. Score 1 for Microsoft on reliability, if not flexibility.

One issue in the last 10 years is that systems that could have been built quickly and easily with (mostly proprietary) RAD tools in the past are now built with Java code on J2EE platforms instead e.g. in the hope of avoiding vendor lock-in with proprietary tools. Although this approach often includes the use of high quality open source libraries, writing code this way is slower and requires many more lines of code, and J2EE is far more complex than most RAD tools, indeed far more complex than many business applications really need, so inevitably you get more errors. Applications that could have been built in weeks 10 years ago now take months to implement. Of course, there are Java-based RAD tools, and alternatives for some applications such as Ruby/Rails etc, but not many people use them, because they might have to train their staff to use them.

So there may be good reasons for choosing Java/J2EE for many projects, but often the added complexity and cost may not be worth the presumed benefits. After all, a Swiss Army knife is a handy general purpose tool, but you probably wouldn't use it for anything requiring specialist equipment.

Java/J2EE has also become something of a monoculture in many areas of IT. Computer science graduates usually know Java, so if you're hiring staff for one of the big programming barns in Mumbai or Bangalore, you can find 100 Java programmers pretty easily. But this means you have to push your customers to use Java/J2EE, or you might actually have to invest in training your staff in more specialised technologies. As the role of programmer is increasingly being de-skilled to fit with a production-line approach to software development and make it easier to outsource/offshore "unskilled" work, many people do not want to remain "mere" programmers any longer than they have to, and their employers are also less inclined to invest in developing their programming skills.

The end result is a kind of Walmart effect, where the current commercial IT development market is geared towards a one-size-fits-all mentality, which in many cases is Java/J2EE, implemented by inexperienced staff who rarely know or care much about other technologies (e.g. databases) and so tend to do everything in Java because it's familiar, even if it's inappropriate for the task. This tends to produce over-engineered, bug-ridden, complex systems that cost many times more to implement and maintain than alternative approaches, but at the same time force the customer to keep paying you to fix them because nobody else understands them anyway. So despite the "open" Java approach, you can still end up locked into relying on a particular vendor, but now you can't even rely on your software to work.

If you need any examples of this, just look at all those successful public sector projects delivered on time and under budget with Java/J2EE in recent years...