Bruce Tate's Blog

Extreme Programming Archives

Spring and the English Archer

2004 is a year of revelation for me. Better, Faster, Lighter Java was a fun book to write, and I learned tremendously in writing it. A closer involvement in the Spring project, and in the Java persistence community, also led to similar discoveries for me. It’s humbling to evolve my thought process in this very public forum, and thanks for sharing the ride. In this blog, I’m going to ramble a little bit. I’d like to draw some analogies to what I think is going on right now in the Java community.

In recent days, I've been reading Bernard Cornwell's Archer series. It's a book on historical fiction. I've read with some fascination the impact of the English archer on the battlefields in the 100 years wars. The bows were 6 feet long, and they took 100 pounds of pressure to draw. To wield such an incredible weapon, archers trained from childhood. The arrows were three feet long, and exerted enough force to pierce the thickest plate armor. They had great range. While they couldn’t fire as far as a crossbow, six to seven arrows could be fired for every one crossbow bolt.

No one seems to know why the English were able to employ archers on the battlefield in such great numbers, while other countries were unable to leverage this weapon. We just know that it changed battlefields, and in some ways, the course of history itself. Of course, we’ve come to call tools like this one disruptive technologies.

Throughout history, we’ve seen many different disruptive technologies: the printing press, cars, trains and computers. If you look at this industry, we’ve also seen other disruptive technologies: personal computers, the Internet, Windows and Java all changed the way that we use computers in fundamental ways. On a smaller scale, some programming paradigms are also disruptive. I believe that new programming models emerge because the old ways aren’t powerful enough anymore.

Think about a typical problem these days. Many of us try to build an application, with a user interface that can work on most of the computers in the world, and communicate with thousands of disparate computers, all in seconds. We tie these seamlessly to databases or other resource tiers, and can even do distributed transactions between them. But that’s not enough. As the programming problems get more complex (and they are), we continue to need to raise the bar. I think that we’re going to see aspect oriented programming in the main stream. It will probably not happen as soon as some expect, and it may prompt a completely new language from an unexpected source, but when it happens, it will be pervasive. In other cases, disruptive revolution comes from what you do, rather than what you use.

As an extreme sports adventurer, I can relate. When we learned to run waterfalls with more speed and at an angle, the ski jump, and later the boof move, was born. These moves let kayakers separate themselves from the vertical water of a large waterfall, and at the same time, dangerous hydraulics below such beasts. We could then run much more extreme rapids with less effort, danger and skill. As a result of these techniques and those like them, the popularity of the sport is exploding. As a weekend extremist, I’ve run a waterfall that were considered unrunnable just fifteen years ago. It was the technique, more than the kayaks, that changed, but new kayaks emerged to take better advantage, much like AOP is growing and maturing without an ideal language.

Dependency injection is leading to such a disruptive revolution. I think it’s leveling the playing field between smaller open source teams and the big J2EE vendor, such that open source projects like Spring can compete and in many ways, surpass, the software that’s coming out of the big container vendors. Spring, which already lets you do declarative transactions with objects that can be deployed outside of the container, just announced support for JMS, and will follow quickly with support of JMX. They’re integrating AspectJ. But what’s amazing to me is that Spring is still very clean and modular.

Dependency injection is disruptive because it’s simple, and it brings elegance and clarity to a design without oversimplifying an application. This weapon, though, does not need training from childhood. It requires a little restructuring of what you already know, and a whole lot of common sense. From clarity and simplicity comes better structure. From better structure comes taller towers, in the form of applications with more power and flexibility than we’ve been able to achieve in other ways. This much is clear to me now.

I see Spring as perhaps the fundamental driver behind dependency injection (it’s the lightweight container with the broadest market acceptance and momentum). In an earlier blog, I also mentioned that Spring is a good way to introduce AOP into the mainstream in a safer, more limited way. That’s why you’re seeing me bet more and more of my career on it. It’s disruptive. It gives me more leverage and power than I’ve ever had before.

People of the elephant

The "elephant" article that java.net published last week was probably my favorite that I've ever written. Your responses made me work. After hundreds of blogs, e-mails, forums and phone calls, I'm still amazed that it struck such passionate feelings from my audience. (In an amusing twist of fate, Amazon chose that week to report that my new book, Better, Faster, Lighter Java, had not yet shipped, though they were taking orders. Rather than answer each blog in a boring tit-for-tat, I'm going to make more amuzing but practically useless gross generalizations. These are the groups of people that responded to my article.

• Some just like chicken better. Call this the tribe of chicken hunters. And I say, "More power to the chicken!" Some called me to ask me how to move from a diet from elephants to chicken. I learned that more and more people are learning to hunt chickens. Spring Chickens are now taking off and downloads are in overdrive. Hibernating chickens have never been stronger, and Kodo-chicken is having spikes in orders. Like their prey, some chicken hunters are not as always as bright. That’s OK. You don’t have to be to eat a chicken. Others are brilliant, including those that wrote the manifesto about changing our diets from elephant to chicken. Still others are purely pragmatic, seeing chicken as a way to save time, money and effort. Recognize this tribe from the elephant-sized footprints on their chest. Make them eat an elephant again at your own peril. I firmly believe that most of us will be chicken hunters soon.
• Some are grudgingly still working with elephants, but are having a difficult time. Let's call this the starving hunters. They stare longingly at chicken, but this tribe's betting everything on landing an elephant. They say that they just don’t have time to learn how to hunt chicken, and you can manage and deploy elephants on a much larger scale. They need some of the other parts of the elephant, too. Smugly, they ask, “Have you ever seen a chicken with a 14-foot tusk?”. Sure, they may take a casualty or two to the hunt, but the benefits outweigh the risks, and they believe that nothing but an elephant will save them, anyway. Recognize them by their battle scars, the racing eyes, and the vaguely frantic conversational style. Don't try to comfort them with alternatives. They probably do need the whole elephant. They may not know it yet, but they’ll probably be chicken hunters soon.
• Some don't care at all. They live in elephant hunting grounds with no other game, and are making the best of it. Call them the happy hunters. They’d adopt quickly if other tastier game moved in, or the elephants moved out. They know their station, and are pragmatically doing everything in their power to make elephant easier to eat. They actually like elephant. And it's been so long since they've eaten anything else that to them, it doesn't feel like eating an elephant. They speak a different language, and don't really care when someone says something bad about their elephants. They shop at SAMS for drums of chocolate sauce, and they use sophisticated elephant cannons that would pulverize other game. They don’t care; they’re hunting elephants. Recognize them by the radios that blare “Don’t worry, be happy,” and their nation's flag, that has a big grey border around a rising sun, with a motto around the perimeter that says "It tastes like chicken."
• Another group lives for all things elephant. Call this tribe the mighty elephant warriors. Their sworn enemy is the tribe of the chicken-hunter. To them, elephants are sacred. They are actually misunderstood, and they actually taste like manna from heaven. When I wrote my article, this tribe said that I was really just talking about EJB entity beans, or stateful session beans, or something else. They insist that if I'd really gotten to know their elephant, things would have turned out differently for me. But now, it’s too late; I’ve insulted their elephant. They get a mighty spiritual boost from elephant. They brag about being able to eat an elephant one bite at a time, but they’ve been gorging since adolescence. They've studied the hunt all of their adult lives, and can bring one down with a Swiss army knife and a toothpick. And it's infinitely easier than bringing down a dinosaur, the sacred beast of their ancestors. They may talk about hunting other game, but they will always come back to the elephant. They love everything about the elephant, and some of them actually want to outlaw elephant evolution. Of course, you may want to be a mighty elephant warrior, but most people that try to pass the initiation get trampled into the ground. A few survive the experience and join some other tribe. Recognize the elephant warriors by the "elfant-4-u" bumper stickers on their hummers.
• Another tribe just wants to pick a fight. Call them the cannibals. Don't try to recognize them. Just turn around and run.
• Then there are those that hunt other game. The biggest is the tribe of the whale hunter. They’re so intensely loyal that some are still trying to hunt whale in fresh waters! Some have heard distant tale of whale-lock-in, so all land-based hunters fear them. The visual-Shrimp hunters distain the whale hunters, and look back fondly on the shrimp-hunting days. You can recognize them easily, because they’re more of a cult than a tribe. Find the leader, and the billion whale hunters will be right behind.
• This tribe has actually never seen an elephant. Call them the cloud people. They are genetically superior, and have actually evolved to a higher plane. Cloud-people were already making advanced Smalltalk when chicken hunters learned that the first letter in chicken was C. They hunt unicorn. They’re completely brilliant, but often completely impractical. There are rumors that some of the cloud people actually started the tribe of the chicken-hunters, but that claim has never been proven. Few will ever be lucky enough to meet a cloud person. If you do, you'll recognize him by the eerie soft luminescent glow from their hair and skin from years of slow radiation.

And what do you think?

1. Is EJB an elephant? I'm not just talking about EJB persistence. Throw in the rest of it too. Is it easy enough to digest and understand? Can you buy it in parts, or would you even want to? Can you effectively decouple everything that you need to, so that you can eat it one bite at a time? Is it easy to teach, learn, maintain, and support? Above all, how does it compare to other solutions out there?
2. Are there other elephants out there that you're already dealing with today? Do you see any other large, unwieldy game, trotting around on the horizon that may grow to elephant-like proportions?
3. If you think that there are some real elephants lumbering out there, how will you choose to cope? Will you choose to go to a lightweight container? Will you radically switch programming paradigms, or move over to .NET? Will you instead just try to work harder and smarter?
4. What's your tribe? How would you characterize it?

Water for your rocket?

Have you seen the 2-liter water rockets? My wife Maggie and I recently bought a launcher to entertain our kids. We about killed ourselves drinking enough rootbeer to empty the rockets, and then headed to the park. My daughters Kayla and Julia stood slack jawed, staring alternately at the aqua missle and their crazed daddy.

You basically take a bike pump, a 2-liter soda bottle, and enough piping to tie the two together. Then, you add water (40% seems to be optimal based on the physics models), and "woosh". You can easily launch the thing 100-200 feet, but some water rockets with modifications have gone much higher than 1000. Pennies per launch. Water for fuel. Non-destructive. Lots of bang for your buck.

2003 and 2004 are turning into productive years for me. I want to introduce you to some of my new rocket fuel. I'm sure that you already know about the pyro rockets (Spring, Hibernate, O'reilly, and Martin Fowler). I want to tell you about the alternate fuels that helped to launch me for pennies. These are the lesser-known, or out-of-favor, people, products and ideas that have had a profound impact on me.

• Mike Clark. Mike is one of the most promising new authors in the J2EE space. People are starting to take notice. He's attracted to the most critical problems: automation, testing, productivity, performance. He knows how to communicate, and he's hooked up with a great new publisher (the Pragmatic Bookshelf), with fantastic editing support. It's hard to find good programmers, but he's a great one. It's harder to find people who can communicate, but he makes a great impression to his class rooms, his clients, and his partners. And he delivers, on time and under budget, every time. Mike worked with me to write Bitter EJB, and I used many of his ideas (and those of his publishers) to consolidate into Better, Faster, Lighter Java. His customers, students and readers alike rave. They're right. Read his stuff at clarkware.com.
• Justin Gehtland. Justin, quite simply, is the best co-author I've ever had. He's a zebra who looks equally good in white (Java) and black (.net). He's more popular in the .net space, but he's a very solid Java guy as well. He writes clean, simple code. Further, he knows process. He's got a well-grounded way of dealing with his clients. It's not fair to have such a nice guy, based on solid founding principles, who can also code, write, communicate, and see the big picture. Justin's biggest contribution to our community is that of a pragmatic, who understands what both Java and .net have to offer.
• Jay Zimmerman. Jay is a shrewd businessman who has quietly built an alternate conference to the JavaOnes of the world, and he's done it with a consistent vision and quality. Jay's biggest mark is on local Java communities. He's provided good speakers to Java User's groups, and has brought a high-quality symposium series to local communities not named San Francisco or New York. He's always looking for ways to improve. My favorite thing about Jay is that he always negotiates with a win-win attitude. Where JavaOne has become the voice of the big money, NoFluffJustStuff has become the voice of many important independent consultants. It's a fun conference, and it gives a voice to many who would not otherwise have one.

• Bloomba. If you know about Bloomba and have tried it, and you have a choice, you're probably using it. This e-mail client makes it easy to filter spam (90% plus hit rate for me), and do instant searches (less than a second for over 5000 emails....also searches content of attachments.) I used to spend a whole lot of time organizing into filters. Now, I just leave it all in one big box, and google, er, bloomba, for whatever I need.
• IDEA. I know, I know. It's already a popular tool. But I've rediscovered it after a brief time with Eclipse. It's simply the best refactoring IDE available. Sure, it's not free. But I'd gladly pay to help this great company produce great products. They get it, and refactoring has never been easier. I believe that it's healthy to buy great products, even when a slightly inferior open source alternative is available. It fuels innovation and progress.
• Kodo. I love Hibernate, and frequently recommend it, but for bigger, more sophisticated deployments, I usually recommend Kodo. It's fast, simple, and has some of the enterprise management tools that Hibernate lacks. Their CEO Neelan claims that they've never lost a performance benchmark since they released 3.0, and I believe him. I particularly like some of their performance management add-ons, and their mapping support is among the most flexible in the marketplace.
  
  SShhh. I heard it through the grape vine that the Spring project and SolarMetric are working together at the highest levels to provide first-class integration. I hope that this support is extended to cover JDO 2.0 generically.
• The Pragmatic Bookshelf. Dave Thomas and Andy Hunt are at it again. I've had a great experience with O'Reilly and my editor with Better, Faster, Ligher Java (Amazon got their shipment yesterday!), but you already know about them. I'd like to mention a pseudo-competing publisher in the Pragmatic Bookshelf. (O'reilly handles distribution for them.) They're writing smaller titles with ideas that last. They boil a subject down to the basics. I've loved the three books that I've seen. It's fundamental: we should weigh books on the quality of the ideas, not the quantity of pages. No more phone books!

• Test-driven development. This has been popular in the lab, but has taken a long time to take hold on production teams. Let me be clear. If you want to give your water rocket an extra boost, look to TDD. It's like pure H2O: raw simplicity and power. It forces cleaner designs and injects some automatic discipline. Further, since newer techniques like lightweight containers, AOP and dependency injection make it easier, it's time to give TDD a second look.
• Context inheritance. Spring's biggest impact to my life has been the improvement to testability. I can test out of the container, and I can stage small-scale integration tests, by providing a custom context for test cases. The problem is that this design philosophy leaves me with dual maintenance for my testcase contexts. Instead, I can use Spring's context inheritance to manage my testcases. The root class can use the production context, and every more specialized test case also has a more specialized context. Very interesting. I can then stub out a database witn an in-memory implementation for quick GUI tests, add specialized test data, or simply test a small subset of my overall system...all without undue repetition of contexts.

Water for your rocket. Always remember to launch from a safe distance. The fuel's more potent than you think.

This work is licensed under a Creative Commons License.