all bits considered data to information to knowledge


IT debt, Inflated Expectations and Software Engineering

The IT debt is defined as the cost of clearing the backlog of maintenance that would be required to bring the corporate applications portfolio to a fully supported current release state.

It is estimated that the Global [IT Debt] to Be $500 Billion This Year, with Potential to Grow to $1 Trillion by 2015 (yes, all capitals, courtesy of Gartner).

Ah, the novel idea of functionally correct supportable code! There is a lot of poorly engineered software out there, and to some people it might come as revelation that a particular technology is largely irrelevant to the IT debt costs.

The CAST Report on Application Software Health sheds some light on "technical debt" or, as Gartner defines it - "IT debt", details. In absolute uncontested lead is...drums rolling... Java EE with average $5.42 of technical debt per line price tag (the costs of fixing the code). By comparison, COBOL has the lowest score at $1.26 per line of code; much maligned Visual Basic (.Net version excluded) fares much better - approximately the same as C.

Bill Curtis, chief scientist at Cast Software offers his explanation for the COBOL stellar performance - the code base has been around for 30+ years, and had better chance of being fixed during this time. As for Java, Bill said he can only offer a speculation  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."

While I  agree with the diagnosis in principle, I'd like to point out that there were many more people "who aren't gurus in software engineering" coding in unpretentious Visual Basic  in its heyday (versions 3 through 6), and yet it came up with much better scores. With all the hype surrounding Java development in the late 1990s/beginning 2000 a lot of people led to believe that they are writing solid code just by virtue of coding in Java (on one occasion I was told that the system is "inherently scalable because it is written in Java"!). Call it inflated expectations: the built-in OOP, automatic memory management, structured error handling, byte-code portability and so on (add your favorite silver bullet here...) were expected to make up for the lack of software engineering savvy. Well', it did not - and the proof is in.

The same scenario played out with every technology out there. There is no substitute for sound engineering design and architecture - regardless of whatever technology that might be used to implement it.


P.S. It had occured to me that this is somewhat related to "Software Debt" concept explained in editorial blurb of the book by Chris Sterling -  "Managing Software Debt" - as follows:

"Shipping imperfect software is like going into debt. When you incur debt, the illusion of doing things faster can lead to exponential growth in the cost of maintaining software. Software debt takes five major forms: technical, quality, configuration management, design, and platform experience. In today’s rush to market, software debt is inevitable. And that’s okay—if you’re careful about the debt you incur, and if you quickly pay it back".