Skip to main content

Therefore, BOOM!

Posted by daniel on November 7, 2003 at 4:57 AM PST

Sometimes a solution is so compelling that you immediately get it. You understand the problem space and the need for a solution and suddenly one appears that is appropriately simple. Therefore, BOOM!

Ken Auer's essay Therefore, BOOM! is featured in the Java Patterns in Projects and Communities today. By "BOOM!" Ken doesn't "mean it has to be startling, just an obvious release of tension as the forces are resolved." Ken writes

The best patterns give the sense of tension and release. As I read them and the forces are exposed I'm saying... "boy, this is a tough problem." or "I've never realized the subtle nuances that really need to be balanced in order to avoid further problems down the road.". Then, when I read the solution, I say, "Cool! This does a masterful job of balancing the forces without adding more problems than it has solved." Or to put it another way, it goes from "Huh?" to "Uh-oh" to "Oh no" to "Ahhhhh...". Of course the magnitude of the tension building and releasing is somewhat tied to the nature of the problem. I believe the GOF format of documenting patterns is a handicap toward achieving this goal, although it does not render the goal impossible.

I have learned a lot from Ken over the past few years. This paragraph describes a common pattern for some of the best articles as well. A problem is explained. The problem has to be real and not just something contrived to set up the solution or a programmer error that could have been easily avoided. Then a way to resolve the problem is presented. This solution has to be compelling but not too simplistic.

Tucked in at the end of Ken's paragraph is the phrase "I believe the GOF format of documenting patterns is a handicap toward achieving this goal". Ken argues that patterns should not require deep study for understanding. A good pattern, article, or book should convey its meaning and intent quickly and clearly. "Just as we can gain a deeper understanding of wisdom by going back to it more than once, we can become more confused by dwelling on foolishness. Personally, I've only got so much time. I do not have the time to read everything I've ever seen identified as a pattern, and I certainly don't have the time to read them multiple times and study them deeply."

I've been thinking a lot about Apple's Rendezvous technology lately. I first saw it at Apple's May 2002 Developer conference. Steve Jobs opened his laptop and brought up the iTunes music application. Someone joined him on stage and opened their laptop and started up iTunes and the audience saw the second person's music collection appear in Jobs' iTunes all ready for streaming. A bunch of us from O'Reilly were there and we couldn't stop talking about Rendezvous over lunch. Apple had provided the motivation before presenting the solution. One of the obvious comparisons to make was with Jini technology. We wondered how much bigger Jini adoption would have been if there had been a more clear description of the benefits in non-technical terms.

Even though Auer doesn't recommend the GOF format, he acknowledges that many will continue to use it. His suggestion is that it can have a much bigger impact if

you work a lot on the motivation section and keep the tension building/release idea in mind as you do it. I find that without this in mind, the GOF form encourages spreading the "solution" (Therefore, BOOM!) portion around to a lot of places so it is hard to get the dramatic, one sentence release (the BOOM!). I'd recommend putting the one or two sentence "release" (the BOOM!) at the end of the Motivation section. I could be convinced that it may lie in another section. I'm not so sure I could be convinced that it could be left out and serve well the purpose of patterns… capturing and proliferating wisdom.

The Jini Community forwards an email from Gregory Kapfhammer. Kapfhammer is teaching the Principles of Distributed Systems at Allegheny College and writes, "If you have ever been interested in learning more about the theory and practice of distributed systems, then I would encourage you to take a
look at the homework and laboratory assignments."

In Also in Java Today , we point to a tech tip on Handling Exceptions. If you received this in email, you may want to check out the web site for the actual code for the final example. The tip shows examples of what can go wrong with not handling or ignoring exceptions. Space constraints require the tips to be focused. As several readers have noted, finally was not introduced in this tip and will be in a future tip.

For your friday fun, we followed a link from the Java Lobby . I have learned a lot from Rick and the crew over the years, but the Monkey Shakespeare Simulator may be my favorite link of theirs yet. This applet explores the idea that "If you have enough monkeys banging randomly on typewriters, they will eventually type the works of William Shakespeare." Sixty-two days in, the most the monkeys have managed are the first eight characters of "Cymbeline".

The first of today's featured Weblogs , is Navaneeth Krishnan's first post The hundredth monkey. Krishnan's hundredth monkey is different than those in the Shakespeare simulator. Here the hundredth monkey principle has to do with isolated groups making parallel discoveries at nearly the same time. Navaneeth asks " Does a 'collective unconscious' really exist? Do morphogenetic fields influence human behavior? Can one's perception resonate with the vibrations of another's consciousness? Are there inexplicable forces acting within a community which lead to collective behavior?" I think back to isolated but contemporaneous inventions of the same thing, such as the Calculus, and think that sometimes the time is right for an invention and it is natural that more than one instance will arise. Today this leads to the hundredth lawyer principle - but that's another matter. Krishnan's entry details his development as a programmer.

Simon Brown checks in with his First impressions of Clover. Clover is "a code coverage tool that will help you identify what sort of coverage you are achieving during execution of the code. This means that you can see how much of your code is called when your program is being run, and also how much of your code is run during the execution of your unit tests. In addition to this, it can tell you how many times each particular line/block has been called and also how many times conditionals have been evaluated to true/false."

Sue Spielman has been busy this week presenting and checking out the Java Highlights from Borcon. One of her favorite moments was the demo of Project Looking Glass "With a 3D screen display, translucent to opaque windows on mouse-overs, and this totally cool feature…click on an open window regardless of what is contained in the window (graphic, text, streaming media) and the window will flip around to allow for notes to be taken on it. This got a large round of applauses. But that wasn’t all; the windows can be rotated, flipped, angled and tilted on the screen for position however you like in order to keep your workspaces organized and keep your desktop uncluttered while still having visual access to information." Now that Sue is done at the Borland Developer Conference, she is polishing up her next article on the JSTL that will appear next week in

In today's News Headlines :

Registered users can submit news items for the href=""> News Page using our
news submission form.
All submissions go through an editorial review by news director Steve
Mallet before being posted to the site. You can also subscribe to the href=""> News RSS

Current and upcoming Java Events:

Registered users can submit event listings for the href=""> Events Page using our href=""> events submission form.
All submissions go through an editorial review before being posted to the

This blog is delivered weekdays as the href="">Java Today RSS
feed. Once this page is no longer featured as the front page of href=""> Java Today it will be archived at href=""> You can
access other past issues in the href=""> Archive.