Java Apps Have the Most Flaws, Cobol the Least

dcblogs writes "An analysis of 745 applications for violations of good architectural and coding practices found that Java applications had the most problems and Cobol-built systems, the least. Some 365 million lines of code were analyzed by Cast Software to assess 'technical debt,' or the cost to fix the violations. Java was calculated at $5.42 per line of code, while Cobol did best at $1.26. Cobol code had the least number of violations because programmers 'have been beating on it for 30 years,' said Cast. As far as Java goes, 'there are many people going into Java now that really don't have strong computer science backgrounds,' said its chief scientist, Bill Curtis."

Comments

so?

[masternerdguy]

That COBOL code has been maintained for like 30 years, it would naturally be rock solid by now.

Re:so?

[laejoh]

COBOL is written ALL CAPS. That's why it's more stable. The characters don't fall down so easily when they are ALL CAPS. Java has to many funny characters like { and }. They have no stable base and tilt over to easily. Compare { with PERFORM and } with END-PERFORM and you know enough!

Re:so?

[Anonymous Coward]

COBOL also is very inexpressive and requires more lines of code to do the same thing, so saying "dollars per line of code" is not very useful.

In fact if you ever hear the words "per line of code" you can just assume that you're talking to someone who doesn't actually write code.

Re:so?

[DesScorp]

COBOL is a good language for what it's intended for... business software... but Comp Sci people didn't like it because it wasn't "elegant", which is pretty much an argument of style, anyway. I liked COBOL just fine in college, and it made sense for its intended purpose. I find that most of the people that mock COBOL have never coded in it. It's a solid language, well-liked by those that use it. If you're a programmer and you don't like it, well, then I'd advise not taking a job programming it. Plenty of other C/C++/Java, etc jobs out there.

Re:so?

[johnlcallaway]

I wrote COBOL code for 15 years, and agree 100%. I could churn out complex multi-level reports in half a day that WORKED because I had been doing it so long and had a method. My only complaint with COBOL was that it didn't support recursion or dynamic arrays. Most complaints were that you had to type a lot, but what most people didn't realize is that good data design up front allowed for the use of commands like 'move corresponding' and 'add corresponding' to make the actual program code simpler. I've noticed with modern coders some of the same tendency to make the data definitions fit the code instead of the other way around.

I now write in Java, and spend most of my days rewriting very poorly written C++ into Java. Not because C++ isn't a good language, but because the people that wrote the code had no idea how to write code, let alone C++. Overly-complex designs for simple tasks, using flags instead of try/catch blocks for error handling, and using codes (i.e. if flag = 1) instead of enumerators or constants to make it legible.

I also know that my code three years ago is nowhere as 'good' as the code I write now. It's easy to teach someone how an if..else statement works, or the difference between static and class objects. But to help them to understand principles, like when to use static or class methods or objects, they really need to write code for awhile and get a grasp on the concepts. And as I write more and more, I learn new little things. Plus the language itself advances. After about 10 years of coding in Java, I'm pretty decent at it now. But I'd say my first 2-3 years resulted in some pretty bad code, and the next 5 some that was OK, but could be improved. I still look at code I do today with a critical eye, always wondering what I could do to make it easier to write and maintain and more efficient.

I had a financial engineer come up to me a few months ago that didn't understand why he just shouldn't use static methods and objects for everything. He read the book, he knew how to write code. What was all the fuss about anyway?

I just sighed and did my best to explain to him in 15 minutes what I have learned over the last decade. I think he understood as he walked away, but his boss is not my boss, and I don't have to support his code. The rest of the financial engineers use SAS, so I probably should care since I'm sure I'll be the one to support it when he leaves....

But it's probably easier for me to fix it then than to try and beat good coding practices into him now. I've got my own schedules to keep....

Re:so?

[Bill, Shooter of Bul]

Yes, its difficult to keep up with the suicide rate.

Cobol programmers "beating on it for 30 years"

[Anonymous Coward]

So... masturbation makes you a better programmer? That explains a lot about guys living in their moms' basements.

Technical Debt

[Nittle]

In today's agile world, who gets time to maintain technical debt. How does paying technical debt ever give your app that new feature that your marketing department is pushing for -- to have out by tomorrow. I think the rules have changed in how companies push their software development organizations to deliver software. That may be the biggest reason that quality is different than it was. That and the other programs have been worked on forever.

Conclusion...

[Anonymous Coward]

this is no assessment of Java vs Cobol, but of seasoned programmers vs half-skilled newbies.

Java apps are probably most widespread

[coder111]

If you look at enterprise world (which is what they analyzed) you'll see that either Java or C# are most widely used. Which means most new/inexperienced/crap developers get to work on these projects in Java and C#. Which again means most mistakes & hacks & silliness. All the speciality stuff using exotic languages gets better people. And cobol applications in use today are either really mature and good quality or discarded years ago.

There are very few good team leads and architects who actually stand their ground and demand both quality from developers and resources to do quality work from their managers... And there are probably fewer managers who understand that quality needs time & resources...

--Coder

Coding Practices?

[Murdoch5]

The only real coding practices that mean anything are:

1) Does the program work
2) Can the program be maintained
3) Can a normal developer understand your program
4) Is your program acceptably bug free

When you start breaking down coding practices into line formatting and variable names and etc... etc... etc.... your no longer programming your doing document management and personally I'm not going to write my embedded systems firmware in word so let me program.

Re:Coding Practices?

[gstoddart]

I SWEAR I'm not making this up: a manager once criticized my code as being too terse

And, as a developer who has done code reviews for a long time ... I've had to tell other developers the exact same thing. Because it was too fscking terse.

In our shop, you needed a comment before your function describing what it was for, magic numbers were strictly verboten, and we expected function/variable names to actually have some descriptive value so we can tell what they're for, and anything non-obvious needed a comment.

We'd still get functions with three-letter names which were meaningless, variables like "b1" and "b2" which conveyed no information whatsoever, and generally crap code. Those guys didn't last long because they couldn't understand why their code was unusable in a production codebase.

"people have to read and understand it before they can modify it". He saw no irony in that statement.

Maybe because there was no irony? I've seen a bunch of young coders who claim that their code is so elegant and obvious as to be easily maintained. I've also shoved the same code back in their face after 3 months and said "fix this", which got me a "what's it do"?

If you think there should have been irony in his statement, maybe your code isn't very good.

Always assume that someone half as clever as you think you are is going to be fixing that code with great time pressures and in the middle of a bad day ... because quite likely, even if it's your own code and you fixing it, that will be true. People who act otherwise are likely a liability in the long run.

I have seen far too many coders who thought they wrote clever code, but after six months couldn't follow their own logic in order to be able to debug it. If the original author can't debug it, WTF is anybody else going to do with it besides rewrite it? (Something I've had to do before.)

Re:COBOL

[laejoh]

Let me, an old Cobol fart, just answer by repeating: "As if requirements never change".

Re:COBOL

[tajribah]

Besides, if you have a 1000-line Java program and a 10000-line COBOL program doing the same task, which is going to have less bugs per line? :-)

What the programs do...

[jellomizer]

Most COBAL applications while do a lot of processing they are not required to do much in terms of advanced coding. We expect more out of Java Programs then we do with Cobal. Java Apps need a cool fancy UI that handles every users whim. While the COBOL app has a menu you type that Item fill those fields and the record and hit process and wait.

If we were to one for one recreate those COBOL apps in Java without anything new. I will bet those Java Apps will run just as well.

Re:SQL too

[toadlife]

SQL injections typically affect php apps, and php has syntax somewhat similar to java. Therefore the GP's theory remains solid footing.

Re:Interpreted languages?

[Anonymous Coward]

Here are the languages and numbers of applications submitted for assessment.

Java EE 339
Oracle Forms 39
Oracle CRM 12
Visual Basic 14
dotNET 51
ABAP 59
C 14
C++ 9
COBOL 80
Other 11
____
total 745

339 Java, 14 C, 9 C++???

The sample size and distribution renders all statistical conclusions meaningless! Just another piece of corporate bullshit...

Re:SQL too

[CastrTroy]

The mysql_escape_string, mysql_real_escape_string, mysql_i_mean_it_this_time_escape_string thing probably has a lot to do with the sql injection vulnerabilities, not to mention that before mysqli, you couldn't even use prepared statements. That and the number of php "tutorials" on the web that don't even mention mysql_real_escape_string or prepared statements, leads to PHP being particularly bad. Add that to the fact that PHP is what is avaiable on cheap web hosts, and that it's the language of choice for many newbie programmers, and you go a recipe for disaster. The SQL injection problem isn't limited to PHP, but PHP probably has the biggest problem with it.

Re:SQL too

[BitZtream]

I've developed applications which have > 10k users in the following languages:

C/C++
ASP
ASP.NET (C#)
VB6
Java
PHP

While my prefered language for getting 'real work' done is C/C++. Over the years I've learned that the only real reason Java applications suck is because Java is easy to deal with (Like VB) so it brings in a metric fuckton of really shitty managers who think they are developers ... who write REALLY REALLY REALLY shitty apps.

Until about 3 years ago, you would not catch a shitty PoS java app on my machine, slow bloating piles of crap ...

Then I was forced to write a java servlet because I needed a good SVG renderer, and Batik is about the only one that doesn't suck ass.

From that experience I learned that Java indeed IS nice, and the JVM (on Windows and OS X at least) is pretty damn impressive (not perfect, but still impressive). I quickly learned that writing fast, quick to load Java apps is really trivial. In fact, they only way I can make a Java app suck is by doing things that I would never allow to be committed to a revision control system I'm in charge of. I am currently incapable of writing a 'slow bloated java app'. It takes me EFFORT to make Java suck. When you see a shitty Java app, you are seeing truely inexperienced programmers who have done things SO AMAZINGLY wrong that you really shouldn't consider them programmers. They aren't, they are just people who wrote some java code.

It's sad that it takes 16GB of RAM just to compile a build of Android. And the funny thing is it kills the whole point of Android being "open". What person has 16GB of RAM on the off chance that they might wanna compile an Android build?

So Open Street Maps isn't Open because I only have 5 gigs of ram in the machine I want to use to process their massive map database into image tiles? I'll have to let them know, here I was, I thought it was just mean for not meeting the requirements of processing a REALLY LARGE complex system that requires extensive optimization in order to actually be useful.

I'm sorry, this is just silly. Open doesn't mean you can use it, it means there are no arbitrary exclusions or inclusions. Open doesn't mean 'meant for everyone and everything for 0 cost'. I'm sorry you're idea of open has been tainted by GPL fanboys, but reality is a little different than what you think it is. Its not my fault you don't have enough RAM to build a system as complex as Android. I say that as what I can only describe as an 'android hater'. I REALLY want to use it for a couple projects, but its just not up to my requirements for lag free operation ... none the less, its really fucking retarded to call it 'not open' because you can't afford the build requirements.

Finally, its fairly trivial to build on less than 16GB of ram, as long as you don't mind waiting a while ... you do know what swap is for, right? I'm sorry you don't understand how things work in the real world, but you don't actually have anything to complain about here.