Beyond Java - Bruce Tate [4]
When a dominant language or technology is in its prime, there's a blissful ignorance stage, when ignoring alternatives works in your favor. Figure 1-1 shows what I mean. When a new language arrives with the power and dominance of a Java or C++, you can afford to ignore alternatives for a while. But if you don't accurately identify the end of the cycle, you can get steamrolled. Suddenly, your competition has the jump on you, with much better productivity leading to better quality, improved productivity, and more customers. When you enter the transition time, you'd better start paying attention.
I admit unashamedly that I liked having my head in the sand. It was easy, and productive, and politically safe. I bet that many of you Java developers act like me. You may have your own reasons. Living in this shelter is certainly easier—doing nothing trumps extra work. You might feel safer—no one ever got fired for choosing IBM. (OK, so maybe Component Broker on
Figure 1-1. For a period of time, ignorance is productive, but the ending of that period can be unpredictable
OS/2 was not such a good idea....) You may have an incredible investment in skills that you believe will not commute, and if you've invested poorly in your skill set, you may be right. You may be bound like a Siamese twin to Java by a long-term project or a group based on the language. Like my reasons, many of these are sound.
Shaken to the Core
After living in blissful ignorance for five years or more, I had an experience that shook me to the core. I led a new start-up down a path that required what I'd consider three of the most productive lightweight frameworks out there for web development of persistence applications: Hibernate, Spring, and Web Work. I knew there were slightly more productive environments for this kind of thing, but they either would not scale (in terms of complexity or performance), or were not popular enough to justify the risk.
My partner and I decided to implement a small part of the application in Ruby on Rails, a highly productive web-based programming framework. We did this not to satisfy our customer, but to satisfy a little intellectual curiosity. The results astounded us:
For the rewrite, we programmed faster. Much faster. It took Justin, my lead programmer, four nights to build what it had taken four months to build in Java. We estimated that we were between 5 and 10 times more productive.
We generated one-fourth the lines of code; one-fifth if you consider configuration files.
The productivity gains held up after we moved beyond the rewrite.
The Ruby on Rails version of the application performed faster. This is probably not true of all possible use cases, but for our application, the RoR active record persistence strategy trumped Hibernate's Object Relational Mapping (ORM) , at least with minimal tuning.
The customer cared much more about productivity than being on a safe Java foundation.
As you can well imagine, this shook my world view down to the foundation. I'm now frantically trying to catch up. It seems that conditions on the river changed without my noticing. I've got to start scouting again.
Boiling Frogs
Let's look at it still another way. You've doubtlessly heard that if you put a frog in hot water, it will leap out, but if you slowly bring tepid water to a boil, the frog will die contentedly. And of course, that's the debate that I hope to trigger in this book. Are the waters around us warming? Notice at the end of my introduction, the owl and the ostrich are exactly the same when it comes to consequences. They may not recognize it, but motivations don't matter one little bit. If the water starts to boil, if the conditions on the river change, they'll both die.
This past year, I decided to wake up to my surroundings to test the water around me. I learned both Ruby and aspect-oriented programming (AOP) . After checking the temperature, I think the water is actually heating up. It's not