CAST has released an intriguing report on Java applications and software quality.
The company analysed 497 applications, comprising 152 million lines of code across 88 organisations and six global industries. It then looked at how software quality correlated with frameworks used.
◾Hibernate has the highest quality scores.
◾Applications built with Struts have the lowest quality scores.
◾Applications that did not use any framework had a huge variance in quality, which indicates that frameworks do in fact help develop applications of predictable quality.
A further investigation looked at what happens to software quality in mixed language applications:
◾Applications built in pure JEE, with no frameworks or multi-lingual mingling, had the highest quality scores.
◾Mixing Java with C or C++ lowers quality scores.
◾Mixing Java with COBOL, Java-DB, and Microsoft .NET delivered higher quality scores.
Frameworks are good but pure J2EE is better? Mixing with C/C++ lowers software quality, but mixing with .NET or COBOL raises software quality? These are odd results, and I wonder if this research is correlating the right factors. Here is a clue:
One common challenge for developers with framework usage is configuring them correctly. CAST data shows that a large majority of applications analyzed had some level of misconfiguration, indicating the need for better training or to simplify the use of frameworks.
I have a hunch that what this research really tells us is that the most competent developers deliver the highest quality code. Maybe the smartest developers do not use Struts.
How do you define software quality? That’s a real fuzzy term and mostly in the eye of the beholder. Quality could be, business value / effort hour, it could be defects / code lines, defects / effort hour, or any other imaginable combination. It could also be cyclomatic dependency numbers etc
I find, in general, that the use of frameworks should be considered very carefully before adopted, more often than not they solve problems you don’t need solving. And you spend most of your time coding around them.
I also don’t see how the choice of language would effect quality, it is the choice of people and their knowledge in said languages, not the language itself.
In general higher skill is required to produce good C++ code (if we measure quality as the minimal amount of code, proper life cycle ideas and pointer use). But that skill does not directly translate to high quality Java code. The reason I say that C++ in general requires more skill is that the language has few restrictions at what you can do, with great power comes great responsibility.
On the up side, a badly written C++ program is likely close to useless for an end user with likely frequent crashes and security issues, a badly written Java/C# is likely to be slow and hog severe resources of the system, but perhaps more useable for the end user.
Either way trying to move the choice of language from the ones writing to someone else is just silly and goes against almost every insight into software development the last ten years where we want to empower the team to make decisions and self manage, as software quality in my mind, comes if the team members make informed micros decisions every minute of every day as developing wading through micro decision after micro decision.
What those people should learn is people skills to vet out the people that honestly knows what they are talking about and are not afraid of open scrutiny of every day’s micro decisions by all the other members as opposed to those that want to work in the hidden or with high prestige.
If there is one trait they should be looking for, it is low prestige, I think it is one of the most dangerous traits that will effect software quality. Low prestige and high sense of responsibility will give you high quality (of course proper skills are important, but they don’t necessarily have to be top notch, at least not at too much expense of the others).
Another thing they should consider is that quality is highly effected by the organization structures that are in place, in general, in my experience, less structure is better, which is counter intuitive perhaps. But each organizational structure is at the same time a barrier, and I bet you will find that the software written has a barrier at that exact same point which is suffering from “don’t change that is working” syndrome and will be one of your bottlenecks..
So leave the technical choice to the people working with the technical issues and spending more time trying to get some science into organizational patterns, or start working the technical trade. A decision made by those that are mostly effected by the decision will be a better made decision as they likely have the highest knowledge, like letting your software uses deciding which features you make….
Yes, it’s correlation, not causation.
Good developers are likely to use Hibernate. That does not mean that using Hibernates makes you a good developer.