According to the recent CRASH Report (2011⁄12) (CAST Report on Application Software Health), the technical debt in Java EE projects is much higher than in COBOL projects.
The core thesis of this report is: The worse the code quality of a software project, the higher the maintenance costs (which is no new insight anyway).
So the question is: Why is code quality in Java EE projects worse than in COBOL projects?
Here are five reasons why this might be the case in my opinion:
- J2EE vs. Java EE 5⁄6 ———————– The report does not tell how many of the Java projects considered were actually J2EE (< 1.5) and how many were Java EE (>= 1.5) projects. J2EE can be considered a flawed standard in many cases.
The main concern is the incredibly high invasiveness of the technical framework code. In J2EE you cannot achieve separation of technical and functional code without a huge amount of layering and pattern application. This leads to polluted and hard to maintain code all the way.
In Java EE 5⁄6 things got much better.
Depending on the ratio of J2EE to Java EE projects considered in the report, the view on Java based applications may be biased towards the worse standard at present time.
Technology and Framework Diversity
The huge amount of possibly applicable technologies and frameworks in all of the layers of a typical Java project raises complexity when different products are used without proper evaluation (and even if proper evaluation has been done). In COBOL there is e.g. no such thing as the web layer (as in the Java EE sense) with all its additional complexity.
New and Immature Frameworks
Because of missing experience with new frameworks or the usage of half baked frameworks developers tend to implement their own solutions that break the intentions of the framework and open side channels. Architecture incompatible code structures are the result.
Developer Experience and Quality
There are many bad Java developers compared to the COBOL world. The average COBOL developer is much older and much more experienced in software engineering than the average Java developer. Computer science graduates with only basic Java knowledge are way too often put on a project without proper guidance by a senior developer just to get the thing done quick and dirty.
Maintenance vs. New Projects
The number of new green field projects done in COBOL is vanishingly low. The majority of COBOL projects is maintenance stuff in long grown and mature applications. Over the years many chances have been taken to fix bugs and refactor code. So the main factors for technical debt have been ironed out long before the authors of the CRASH report took a look at these projects.
While the basic notion of higher technical debt in Java projects compared to COBOL may be certainly true at the time the snapshot was taken for some good reasons, I doubt the reliability of an almighty automatic code analysis tool which is able to produce such testimonies about overall quality of projects with very different technical and organizational backgrounds.