How to make Java Developers 200% more productive

I was fortunate enough to attend a class this week on Ruby on Rails from Chad Fowler. It really opened my eyes about why Ruby on Rails is getting so much buzz in the programming community.

Many in the Java world are feeling less and less productive these days. I know I am. I've told people many times that as crazy as it sounds -- I was able to build useful apps much more quickly in old platforms like PowerBuilder and VisualBasic. (And I'm a Java Trainer for gods sake!). This feeling is very well documented in Bruce Tate's book "Beyond Java".

Java is just too BIG

Rails is referred to as a "full-stack framework for developing database-backed web applications according to the Model-View-Control pattern". WTF? Well, here's my interpretation of it -- it means there's less choice on things that your business users don't care about!

Most of the libraries, and plumbing that you would need in a typical Java Application -- have been chosen or created created for you. You don't have to think about how to make your web application Model 2 (MVC) compliant, or how to communicate to the database properly, or how to perform Ajax web updates, or how to create a REST interface, or what naming convention to use or how to structure your project. It's all there for you! You just concentrate on solving business problems. That's the biggest magic I saw in Ruby on Rails.

Can this level of productivity be achieved in Java? Not quite, Java (as the Ruby people seem to say) isn't as expressive....but we can certainly narrow the gap. Java People...wait...don't head for the exits yet...I say there is still hope!

Java is just drowning in choices.

Let's take Database connectivity -- we have many: JDBC, EJB2-CMP Entity, EJB2-BMP Entity, JDO, Toplink, Ibatis, Hibernate.

What about IDEs? We have eclipse, NetBeans, Java Studio Enterprise, JBuilder, Workshop, Together, Rational XDE, IDEA. And once you choose your IDE -- there's the plug-ins and mods...it just goes on and on....

And what about those design patterns architects like to sledgehammer into developer's minds to a point where they feel inadequate if they don't apply the right patterns. When you start a Java app -- you effectively have a blank sheet of paper -- you got nothing -- everybody writes the same stuff over and over again.

...not a week goes by where I don't stumble across some bizarre Java acronym or relatively-unknown Java open-source library that's in use.


Here's a thought -- apply the 80/20 rule to Java Web Development...80% of the Java Web Developers would agree to design and organize their applications the same way. It's like a world where 80% of the drivers in Washington DC drive Honda Accords and Toyota Camrys (which is almost the case!). An Accord and a Camry are more than adequate to get people from point A to point B. If you truly need an SUV, or a minivan, or a sports car...that's the other 20%. That type of mentality is happening in the Ruby on Rails community. "convention over configuration"

* Agree to only use a Java Web Container (ex: Tomcat)
* Agree on a common directory structure (think Maven)
* Agree on a common naming convention
(how we name models, controllers, tables, columns)
* Agree to use the Spring Framework
* Agree to use the Hibernate ORM library
* Agree to Unit-Test! JUnit, MockObjects, and EasyMock
* Agree on the same basic Ant template for builds, tests and deployments
* Agree to use the same IDE such as eclipse
* etc...

In other words -- minimize or eliminate CHOICE. And for those that have special requirements, those 20% can go off into the weeds and hack their way to the next generation of standards.

Microsoft DotNet has some advantages -- you don't have to decide what server to use, and you don't have to decide what IDE to use (Visual Studio). That's 2 major choices which completely fracture and confuse the Java community. Can't we all just get along?

Less Choice! More Productivity! We need to stop spinning wheels and wasting time on things that should be no-brainers such as database, XML creation, and unit-testing. Business users certainly don't care what ORM package was used...so Shut-up and start building solutions!