Subscribe
Recent Tweets
About Me

I've worked as a consultant and software developer in the financial industry for over 10 years. I've worked for three of the top five Canadian banks in both retail banking and capital markets. I'm currently working with a small consulting firm in downtown Toronto.

« Connection pooling with Hibernate 3.3.x and C3P0 | Main | The future of Java in the enterprise »
Wednesday
Dec222010

Beyond Java

A recent post by Mike Gualtieri of Forrester caught my attention. Mike strongly asserts that Java is a dead end for enterprises and business software should be built with something else. Mike mentions a few different options, but mainly promotes 4GL tools such as Powerbuilder and "all in one" business infrastructure software such as SoftwareAG webMethods. He also touches on BPM and event processing, and by event processing I'm pretty sure he means CEP tools such as Esper.

I've worked with Java for 10 years. (I admit, sometimes it feels like 20. Life isn't pain free.) I've also worked briefly with FoxPro, just spent a few months at a client site digging through SAS code (another 4GL) that's being migrated to Java, and at my previous job I spent almost a month on a  SoftwareAG training course to learn the "webMethods way" of doing things. Is Mike really advocating the use of proprietary, niche languages such as webMethods Flow over Java? Really? I'm not an analyst at Forrester, but I've been turning Powerpoint slides into functioning software for long enough that I feel (just about) qualified enough to chime in on the subject.

I agree with the spirit of Mike's post that Java can be a real pain in the ass to build typical business software with. But the problem isn't Java itself, the problem is that businesses use it for everything. "Want yet another custom time tracking intranet site? Let's build it with JEE! How about a utility that counts the number of ponies in our database? Hell yeah... it's Java time, baby! What about that UI heavy site with super-complex workflow? I've got a fever, and the only prescription is JSF, SPRING, and HIBERNATE!"

People have tried for decades to move away from third-generation languages like Java and towards the nirvana of business folks creating their own apps with some kind of flow-charting tool. One of the first guys I worked with -- he had punch cards in his drawer that *he* punched -- told me all about it. It's the longest running punch line in IT. Mike's post might have been titled "Java is a dead end", but it really should have been titled "third-generation languages are a dead end". And the date of the article could easily have been 1980 or 1990. The dead end is not third-generation languages; languages are merely a tool.

The dead end is producing crap software and expecting to keep up with the rest of the world. The dead end is promoting a stock trader or pony salesman or MBA-type to head up your IT department just because he or she really knows their way around office politics. The dead end is misusing a language or technology for years and blaming the technology and blaming your developers rather than hiring the right people to come up with your strategy and empowering your developers

The only reason these strategies worked in the past is because everyone was fucking up equally. But nothing lasts forever.

Here's a hands-on developer's opinion on the whole "Java is dead" debate, summed up with bullets 'n everything:

  • Java is no more of a dead end than C, C++, or MATLAB. They all have their uses, but using Java for everything is just as dumb as trying to use MATLAB for everything. Stop drinking the Kool Aid.
  • If you want to build great software, you need to hire great software developers. There's no magic tool that will allow your business folks to put together fantastic software all by themselves. These ideas look fantastic in a Powerpoint slide or Forrester report, but fall flat in the real world. 
  • How do you hire great software developers? Be a great team to work for. Understand what's important to top-tier developers. Here's a good place to start (this was written 10 years ago and most companies still aren't close).
  • Treat software development as a first-class citizen of your business if you're going to bother building software. Otherwise, STOP BUILDING and START BUYING; find a trusted partner to build for you, or go back to pen and paper.
  • If you've got a department writing software that operates like anything other than a software business, you've got a bunch of problems that no tool in the world will ever fix. There's nothing worse in the world than software decisions made by companies who treat software as a necessary evil.
  • Stop putting stock traders and accountants and lawyers in charge of your IT department. They may be smart folks, and that kind of strategy may work in politics, but it's painful to watch the decisions these people make day in and day out. Decisions like outsourcing a project to India with almost no oversight and wondering why it looks like a box of pudding when it finally gets delivered. Or having a budget of $100mil and not bothering to hire UX and UI ninjas. (Nothing like saving a few bucks and having colour-blind programmers design your user interfaces, eh. Can we get that icon in cornflower blue?)
  • Developers need to speak up! I've seen projects go completely off the rails because developers allow corporate inertia to dictate decisions rather than technical merits. I've also seen money saved because someone asks the question, "Why are we building a custom app when we can buy it off the shelf instead?"

Just remember that most companies currently shooting off their toes with Java wouldn't fare any better with Ruby on Rails or Python on the Subway. (Actually, pythons on the subway are usually a bad omen. Just sayin'. And don't get me wrong, I think both Ruby and Python are fantastic for certain things, just like Java is fantastic for other things.) Java is long in the tooth, absolutely, but there's still so much goodness in the Java world: GWT, Wicket, Guice, and on and on. Talented programmers can create beautiful things with these tools. Or if you think I'm dead wrong, you can always develop your next app using SAS, FoxPro, and webMethods...

Reader Comments (4)

It is not difficult anyway to make or use a "4GL" approach when developping with JAVA or .NET i think. The tools do exist and if you adopt a simple architecture, you can develop really faster than you could think at first.

But by using a regular and common language, you are not tied to a company, and better, you can use all of the tools and libraries of the ecosystem. 4GL is great for the basic case let say 90% of your software. But if you can't do the last 10% or you need so much time to make it work an 4GL solution might not be as good as it appear first.

We should not think about Java anyway, but about using the JVM or not. Then you can use JAVA, or scala, or jython... And leverage all the ecosystem.

For most IT needs, I think you can stick with either the CLI or the JVM and it will covers all your needs. But don't stick with only one stack inside it. Choose the right tool for the job.

December 27, 2010 | Unregistered CommenterNicolas

Stop putting stock traders and accountants and lawyers in charge of your IT department. They may be smart folks, and that kind of strategy may work in politics

Actually it doesn't work there either. We're billions of dollars in debt ;-)

December 27, 2010 | Unregistered CommenterJon

But by using a regular and common language, you are not tied to a company, and better, you can use all of the tools and libraries of the ecosystem.

Exactly, the key is the commonality of a language. Java is one of the most commonly used languages in the world, so using Java as a glue to bind other components together (including 4GLs) makes a lot of sense. It's easier to hire an experienced Java developer than an experienced webMethods Flow developer.

The problem is that webMethods Flow (for instance) is being marketed as a way to avoid hiring talented developers. Instead, companies are being convinced that they can save a bunch of money by hiring a random pool of commodity developers and train them in house. This usually doesn't end well.

December 27, 2010 | Unregistered CommenterKevin Webber

Actually it doesn't work there either. We're billions of dollars in debt ;-)

Buy gold. ;)

December 27, 2010 | Unregistered CommenterKevin Webber

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>