John Reynolds's Blog

Is Java the wrong language for business programming?

Business needs applications that can be maintained long after the original coder is gone. Java is a great language, but does Java's richness lead to unmaintainable code?

This thought was prompted by a discussion with my colleague, Jim, who has managed large projects for many state agencies over many years. To paraphrase his statement a bit:

"COBOL programmers are interchangeable, Java programmers aren't"

This comment was made in the context of an effort to migrate legacy COBOL and Java applications to an enterprise-wide Service Oriented Architecture. Should we implement all future services in Java, or is COBOL still a viable option?

Jim is not a luddite, but he is tenaciously pragmatic. In his experience in managing large projects, he has found that any competent COBOL developer can maintain another programmer's code, but Java modules are often inextricably tied to their authors. Despite coding practices and design reviews, the Java modules take on the personalities of their owners. The nuance of each Java programmer seeps into the code that they produce.

You can write bad code in any language. You can write good code in any language. Is Jim's observation about Java and COBOL valid beyond his own personal experience?

I can't confirm that COBOL code is easy to inherit, but I can confirm that Java and C++ code is more difficult to inherit than assembly language**. When a language is tightly constrained, you tend to write code like everybody else. Is increased freedom leading to unmaintainable code?

Clarification: My comment about assembly language has caused a lot of confusion among some readers... I'm not suggesting that assembly language is appropriate for business programs, or that it's easier to write or maintain assembler than Java. I've just witnessed more variation in the programming styles of Java developers than in that of assembly language programmers.

Phil Murphy of Forrester Research recently dove into the issue of maintaining applications in his report:Java, COBOL, And Perl Share A Common Problem.

The report is not free to share, but the abstract sums it up:

"The wholesale loss of application knowledge creates most of the maintenance issues, whether the applications are written in Java, Perl, or COBOL."

Phil's telling us that the primary culprit of unmaintainable applications is the loss of knowledge about how those applications do what they are supposed to do, not the language that they are written in.

Let's try to rationalize Phil's findings with Jim's observation and see what we can come up with: COBOL is not a language that encourages abstraction. Java relishes abstraction.

It is relatively easy to inherit COBOL because what you see is what you get. Perhaps a boring narrative, but it has the advantage of leaving nothing to the imagination.

It is relatively hard to inherit Java because you have to comprehend the abstraction. It is like trying to explain a concept by using an analogy. If your listener shares your cultural background, an analogy can open the doors to greater insight. If your listener doesn't get the analogy, you may have slammed the doors to understanding shut. The wrong abstraction choices can destroy code maintainability.

"The problem" with maintaining Java code sometimes comes from "abstracting away" the business process and the business logic. We often use Java to write engines that execute business logic, not to write the business logic itself. In this model, the business logic itself is scattered across numerous configuration files (often written in some custom XML-ish dialects of our own design). Although in some ways an elegant approach, this coding style can be a real maintenance nightmare if executed poorly. If you can't step through the business logic in a debugger, then you probably haven't written a maintainable business application.

Back to my original question: "Is Java the wrong language for business programming?"

The answer is in how you use the language, not in the language itself.

Comments

• The main reason CoBOL programmers are more interchangable than Java programmers is the attitude of the programmers (and the team structure) rather than the tools they use.
  CoBOL programmers are (overall) more alike than are Java programmers, there's less room in their environment for individual expression than there is in the work environment of typical Java projects.
  For example on a major CoBOL project I worked on as a junior programmer there were extremely rigid guidelines that had to be followed. These went as far as prescribing method and variable names (not just naming conventions, but actual names) for nearly everything.
  These conventions were enforced by the source control system so there was no way around them, even if anyone would have dreamed of individualism which they didn't.
  It didn't take me long to figure out that such a stiffling environment wasn't for me and I asked to be transferred to another team writing in Delphi or C++ (we didn't use Java in that company, this was 1997). When no such transfer was forthcoming I left.
  Most Java programmers are less herd animals than that, they'd never agree to having their creativity restricted to such a degree.
  As a result their code tends to take some more time to understand for someone completely unfamiliar with it, but that doesn't mean it's harder to maintain. That incoming programmer has a different set of mental tasks to perform. Instead of having to learn the rigid standards and procedures employed by the Cobol team he has to spend some time learning the mindset of the people coming before him.

  Posted by: jwenting on November 16, 2005 at 12:36 AM

• hm, can't comment on the original question of whether its the 'wrong' language for business programming but thought some the following should be noted

  (i) in my experience, static typing and IDEs give an easy route into project comprehension. For example, this stops (or makes painful/verbose) the style of programming that views all data as hashmaps
  (ii) i don't recognize significantly different coding personalities in the different java source trees i've seen in commercial/open source projects. I've seen cases where programmers were clearly unaware of a particular technique or pattern, but this isn't novel
  (iii) javadoc is your friend
  (iv) the forrester report is surely bizarre for mentioning three specific languages - there are plenty of legacy C/C++/VB projects out there. Losing the original developers of a program and having new developers able to pick it up with zero hassle is a holy grail of development which currently seems unreachable?
  

  Posted by: asjf on November 16, 2005 at 03:39 AM

• CoBOL programmers may be more interchangeable than Java programmers, I dunno. However, I don't think that 'programmer interchangableness' 's really the key to maintainability. For example, how many CoBOL applications were never able to be enhanced to be GUI applications when Windows came along? Most I'll bet. How many Colbol applications were never able to be enhanced to be web-based when the dot-com boom came along. Almost all I'll bet.
  And I've seen several Colbol applications inside big companies that are just not capable of being changed at all because they are so brittle.

  I think that maybe *all* languages are the wrong language for business applications. I think that maybe the answer is to develop metadriven applications where the application's business logic and UI can be made independent any one language or technological platform.
  

  Posted by: emorning on November 16, 2005 at 04:32 AM

• Speaking as a programmer with extensive experience in both Java and COBOL (and nobody who knows the language ever wrote it "CoBOL"!), my take is that many COBOL applications are easier to inherit because they tend to be less complex.

  This is mostly because it's so much more work to get anything done in COBOL, so this implementation friction tends to keep things simple. It's *not* true that it was dreadfully difficult to "enhance COBOL programs to be GUI programs when Windows came along"...although it is true that most COBOL was designed for batch processing rather than interactive use, and this discouraged extensive porting along those lines.

  A mass of undocumented code will be a painful legacy whether it's written in COBOL or Java...or any other language. COBOL programmers as a group have more experience doing what I call "software archeology"...reverse-engineering an application to understand how it works in the absence of actual documentation. But let Java code accumulate in the same way and you'll have the same need. The good news in that situation is that the tools for doing that work are *much* more sophisticated for Java than they are for COBOL

  Posted by: maggieleber on November 16, 2005 at 06:34 AM

• 
  I don't know about Cobol because I have no experience with it. However, I find it easier to jump into java projects when the business logic is isolated to a spot where it is easy to find, written in all in java and uses plain old java objects.

  I'll use swing actions as an example. Keep them all in the same package with good names like AddAccountAction. When I am modifying the action, give me access to methods like List getAllAcounts() and List getSelectedAccounts. Give me the ability to test that action in isolation.

  The same ideas work for report writers, validation, renderers, etc.

  Don't give me business logic that is java mixed in xml and a huge framework to learn before I can get in the mix. Then again, I have been accused by many angry developers that I oversimplify.
  

  Posted by: jasonrberry on November 16, 2005 at 07:23 AM

• I agree with the comparison of Java code to an analogy. If you don't understand someone else's viewpoint, you usually have a hard time picking up their code. I think Java, or any OO language for that matter, gets a bad rap because objects are tough for people to get. If you can't get your head wrapped around the object model, you can't understand the coding logic for it. In my opinion, if you keep the object model simple, the code will stay simple too.

  Posted by: haled on November 16, 2005 at 10:22 AM

• I agree with the author's findings. Java programmers tend to write frameworks that obscure business logic, rather than highlight it. COBOL and COBOL programmers are more focussed on the business logic, and business apps written in COBOL (or Informix 4GL et al) are significantly more maintainable than Java apps.

  The author is right tho, that iits how you use Java. You get given a lotta rope, you have to be careful not to hang those that will be maintaining your code after you.

  Also a business app can be architected in java to be maintainable, or to be unmaintainable -- unfortunately in most cases it is the latter.

  Posted by: evanx on November 16, 2005 at 10:31 AM

• Maybe it's because, as another blogger put it, "veteran Java developers" are more skilled at CSS, XML, Javascript, Struts, etc, whereas a "veteran COBOL" programmer is more skilled with the language and using compilers and linkers. From my experience interviewing several "Java developers", they seem far more skilled with tags than they are with actual Java code. I think the Java platform and language is perfect for business applications, but most Java developers seem to be swamped with so many tag frameworks these days to notice the language. And most vendor rags shovel app servers and more tag frameworks to the IT managers, so "Java" rarely gets a chance to shine for building real business apps in the corporate world.

  Posted by: evickroy on November 16, 2005 at 10:43 AM

• Only know COBOL as an academic exercise, but I worked on a good many FORTRAN programs. The first ones I inherited from a guy that had a very nice straight-forward style. When he took over my programs when I left, I took it as a compliment when he said "these look as if I wrote them myself".
  As for java code, most of other peoples code I have seen seems overarchitected. We have one project at work now that I am not involved in, but had to help a guy get some XML and JMS stuff straight, and I got a shock from the rigid division of layers and then an auto-generated wrapper around that, which I couldn't understand the need for and it just seemed to get in the way, at least when we were doing stuff a little bit different from the "main thrust". But maybe its just me...

  Posted by: tobega on November 16, 2005 at 01:31 PM

• We've been building the intricacies of screens, logic and transactions by hand for too long already - if it wasn't for Java we wouldn't have got even this far. Getting through stylesheets, java script and html on the way through tags and servlets to ejb is a longer path than CICS BMS maps and their modules ever challenged me with. Although some of them came close... Secure, maintainable, adaptable and sociable business systems only become possible when the frameworks settle down to the point where they're taken for granted and all the Java we have to deal with is locked up in jars (nice, civilised open-source jars, of course) driven by XForms and rule definitions.

  Posted by: pdfalcon1 on November 16, 2005 at 02:54 PM

• Having considerable experience with business application development in both of the languages - COBOL and Java, I have to disagree with John.

  Perhaps everybody on this trail has forgotten that, decades ago, when COBOL was the king, the complexity of IT was far far less than it is today. And that complexity alone can make one feel that Java is not a good language for business application development. But it is not the problem of the language or its suitability for business application development. If one were to start using COBOL to address the complexities in IT today, it wont take long to realize Java is the BEST language for business application development.

  Second thing that apparently makes business app developement in Java confusing to developers (and hence developers mess things up) is because of the choices available in Java platform to develop any single thing in multiple ways.

  Imagine if the only choice available in Java for distributed object computing was RMI over a propreitory protocol and only web framework available was Struts (and you couldnt develop your own), every developer would be so good at both, and developing new applications does not become tough and nobody would have learning curve with developing business applications, except learning the business logic itself.

  The power of freedom of choice (Java) comes with its own baggage. Its like comparing democracy v/s autocracy. Sure democracy is good, but things get done faster in autocracy, when the autocrat (COBOL, CICS) is capable enough.
  

  Posted by: srikanth on November 16, 2005 at 05:50 PM

• Java is an OO language. There are many ways of expressing the same thing in Java.

  To get the flexibility of Java, but standardize code at a given abstraction level, the solution is domain specific languages.

  Lisp/Scheme and Smalltalk are good at doing this. To solve this, design a new language at each abstraction level. Java APIs are similar in this regard but we don't usually use enough discipline and the language is too irregular to raise the abstraction level defining a new "language" at each step.

  Posted by: dog on November 16, 2005 at 06:03 PM

• Hey Srikanth,I'm not sure that we really disagree.I agree with Phil that the difficulty in maintaining applications has more to do with loss of application knowledge than with the language, and I think that the tendency of some Java developers to overly abstract their programs accelerates the loss of application knowledge.We both know that COBOL can be very expensive to maintain... think back to the Y2K hulabaloo, but there was certainly no danger that a COBOL application would be difficult to understand.

  --JohnR

  Posted by: johnreynolds on November 16, 2005 at 07:43 PM

• IT is not categorically true (despite all the 'me too'ers chiming in) that Java is harder to read than COBOL.

  I have, for instance, written Java code *without comments* (I was going to put them in later), and then had a non Java programmer look over my shoulder and say 'oh I undertand what you are doing'. I thought maybe they only think they do, so I asked them some questions about the code they were looking at, and they could give answer them.

  One of my very early contracts was to write code which had to be extended and maintained by non programmers (Electrical Engineers). You learn to express the concepts clearly.

  Another early contract was to debug some code written by one of the better programmers I've ever worked with. It was written in Basic, and he learned to program at MIT before the practice of indenting your code and using procedures instead of gosubs became common.... Surprisingly even uncommented, unindented Basic can be readable.

  (I indented it for him, I'm too anal about things like that not to... :)

  Posted by: rickcarson on November 16, 2005 at 10:51 PM

• I have to agree with srikanth, Its purely that modern business processes, implemented using modern IT methodologies, be it Java or .net or C++, will be implicitly more difficult to inherit for a developer. I myself come from the RPG (iseries camp), and yes the RPG routines I maintain are easier to pick up , run with and fix/enhance, because all they do is read from a file or screen, and write out to a file or screen. I could use Java to do this in one big static main method, and that would be relatively easy for a another java developer to maintain (they may question my choice of design pattern though ;-)), not because of the language choice but because the process is simple and straightforward. The complexity which perhaps is perceived by some as making it more difficult to pick up another's java code isn't to do with the language, more to do with the complexity of modern applications, and the decisions made at design time. Businesses today demand more from their applications, they have to be made more flexible, and target a variety of UI's more complicated than plain old than 5250 emulators, or variants

  Posted by: gupnorth on November 17, 2005 at 03:11 AM

• Gupnorth,
  I certainly agree that today's business applications are being asked to do more... I just think we need to do a better job of decoupling the business logic (which is what has to be maintained) from the plumbing, and we need to make it easier for those that inherit our code to debug that business logic.

  Domain specific languages could help, as Ben Galbraith recounts in his latest blog entry, but I worry that we won't have the right tools to debug DSLs.

  I tend to agree with pdfalcon1: "Secure, maintainable, adaptable and sociable business systems only become possible when the frameworks settle down to the point where they're taken for granted and all the Java we have to deal with is locked up in jars (nice, civilised open-source jars, of course) driven by XForms and rule definitions."

  --JohnR

  Posted by: johnreynolds on November 17, 2005 at 04:39 AM

• On COBOL: I worked at a bank last year that had a problem with a legacy (third party) COBOL module that was leaking memory. The vendor admitted that there was a problem, but noone could fix it. And lots of COBOL programmers had tried. So it didn't seem like the 'interchangeability' gained us anything there.

  The solution? Restart the server nightly. Ick.
  

  Posted by: rickcarson on December 05, 2005 at 03:21 AM

This work is licensed under a Creative Commons License.