I came to a realization this weekend. The Java web tier is suffering "The
Innovator's Dilemma", an idea explained in a book by the same name from
Clayton Christensen. It's an examination on how you can listen to customers,
provide them with what they want, but still lose out -- because a cheaper,
not-as-good but good-enough competitor comes in and eats your market.

This thought hit me as I was speaking at the "No Fluff Just Stuff" conference
in Austin. It's primarily a server-side Java conference, but during the open
panel session, attendees asked question after question about Ruby on Rails.
Many speakers said they liked it, and one had even written the new Rails
book from the Pragmatic Programmers, the fastest selling book at the show.

I think people (myself included) are drawn to Rails because it promises
simplicity. In programming these days, cheaper isn't about price, it's about
mental effort. So a language like Ruby and an environment like Rails that
promise us *less* has a strong appeal.

Java's trying to deliver simplicity through new features. Oh the irony! Java
Generics were added in Java 5 to make things easier, and while they can help
newbies ignore casting, they make guru-level knowledge of the language all the
harder to maintain. What does the following mean anyway?

public class Enum<T extends Enum<T>>

Java Metadata similarly was intended to make things easier, but in the web
tier we're seeing metadata annotations used to duplicate what previously was
done in deployment descriptors. Having two ways to do something, even if the
new way might be more elegant, isn't a simplification. To deploy you now need
to look through XML files and source code to learn what's needed -- or use
special tools, a clear admission you've gone way beyond simple.

I heard today from someone involved with Java at Sun that Ruby on Rails
"doesn't scale". Exactly! It doesn't have to. It's not as good, but it's
easier (read: cheaper) and good enough for most. Like all disruptive
technologies, it'll only get better. It will scale better. It will add
two-phase commits and fancy message queues. In the meanwhile it's getting
interest and winning converts with the promise and delivery of cheapness --
mental cheapness.

It's been 10 years since Java started beating C++ in the mindshare game.
Sure, C++ is still widely used, but it's mindshare is small compared to Java.
JavaOne this year they celebrated Java's 10 year anniversary on stage with a
big cake. It reminded me that C++ itself was 10 years old when Java came on
the scene. Remember back: Java wasn't as "good" as C++. It did less; it ran
slower. Its sole advantage was simplicity -- a language easier to write and
deploy -- and over time it got more featureful and faster.

Ruby on Rails today looks poised to eat Java's mindshare on the web tier. If
not Rails, then something else. Empirically 10 years seems like the right
point. Java's viewed as solid and stable, mature enough for the most stodgy
business folks. That leaves a large soft underbelly for a technology intended
to help small teams (10 or fewer) who just want to make a site that's good
enough without paying a high price in mental effort.

My advice to Sun: Own the disruptive technology. Create a group of 7
creative engineers and charge them with approaching the problem from beneath.
Tell them to come up with technology that's "good enough" and a whole lot
easier. To be modern, it must solve the full web application problem, not
just help with individual pages. It must also be AJAX-enabled through and
through. Tell this team they aren't required to leverage existing Java
libraries unless they want to. Their only requirement is that this new
technology should run on the Java Virtual Machine (JRuby or Groovy would be
fine, if the team so judged). This should be what's important to Sun. Give
the team six months to produce an early prototype. Their eventual success
will be judged on if they can eat into Java EE's mindshare. If Sun doesn't
start providing Java heads with "cheaper" technology, someone else will.
They already are.