Tonight I gave the first of two webinars on Test-Driven Development with J2EE. This is a condensed version of my popular tutorial, one which I have conducted at Agile 2006, XP 2006, Agile 2005, SD West 2005 and XP/Agile Universe 2004. This version has new, up-to-date content and provides a key insight into how to test complex J2EE applications almost entirely in memory. If you’re interested, click the title of this entry to learn more. The next show is 10 AM ET Wednesday, August 9.

Have you ever wondered what makes great presenters great? I do, and while I don’t have the secrets to greatness, I can provide a recipe for disaster. You might not have to do all these things in the same presentation to fail miserably, but certainly if you have the discipline to do them all, only failure can possibly follow.

1. Show up late. I imagine few things show less respect for an audience than not showing up on time. If you have problems during your presentation, they will typically be less inclined to give you the benefit of the doubt. Some will dismiss you as a bozo, and you might not enjoy that.
2. Make lame jokes about showing up late. You might think you’re lightening the mood or injective some levity, but subconsciously, you’re probably just trying to deflect responsibility to someone or something else. If you’re late, you’re late—admit it, apologize, then move on.
3. Prepare, a little. The less you prepare, the less likely you’ll be able to handle problems during your presentation, and the less likely your words will hang together and make sense as a whole.
4. Assume your equipment will work. I use a Mac for my presentations, and so I usually ask the host whether I should expect any problems connecting to their projector. It is important to distinguish, “No, there will not be any problems” from “I don’t see any reason why there should be a problem.” The first indicates that previous presenters have successfully connected with their Mac, and the second indicates that no-one knows what will happen. Especially in the second case, prepare for the worst to happen.
5. Don’t have back-up materials. When the worst happens and you can’t use your visual material, you need some kind of back-up plan, whether it’s to ignore the material entirely, draw on a whiteboard or something else.
6. Let technical problems distract you. When your visuals fail you, it’s back to execute your back-up plan and move forward. If you let the problems distract you, then you won’t be present for your audience and they will notice. Put yourself in the frame of mind of someone that doesn’t have visual equipment at all, that way you won’t be tempted to “resume the normal program” if, by some minor miracle, things work themselves out. Concentrate on your message and do your best to present it.
7. Try to fix technical problems while continuing to present. Even if your audience somehow doesn’t notice when you’re distracted, they will certainly notice when you half-ignore them. If you really want to solve your technical problems, excuse yourself, take the time to concentrate on fixing the problem, then fix it. If after a minute or two you have no solution, then ignore the visuals and move on. Do not, however, talk to the computer or projector as thought it were the audience. If you’re going to talk to the audience, then give them your full attention.
8. Make lame jokes to cover your frustration. While I wouldn’t go so far as to say, “Never let ’em see you sweat,” being passive-aggressive in your reaction to your frustration is no good either. Your audience will understand if you’re frustrated, but they want you to get past it and say what you came to say. Making jokes to cover your frustration helps you remain distracted by it, and as I’ve already said here, that keeps your attention divided, and the audience will not appreciate that.
9. Forget your key premise. What worse outcome from frustration could there be than forgetting your key premise? The audience has already put up with your late arrival, your inability to get over technical problems, and now you leave them wondering just what on earth you were talking about. Can it get any worse?
10. Just give up. Your audience wants you to succeed. If you let yourself, you can almost feel them pulling for you, in spite of all the problems you’ve gone through in front of them. The audience deserves your best effort, so giving up near the end, rather than collecting yourself and getting over the finish line is a cop out. If you plan to do that, then don’t accept the next invitation to speak.

For direction and suggestions on great presenting, I heartily recommend following the advice of people like Guy Kawasaki and Garr Reynolds, as well as watching presentations from dynamic speakers like Steve Jobs.

Click the title of this entry for the presentation slides for Test-Driven J2EE from XP 2006.

I have uploaded an improved version of the Test-Driven J2EE project in response to a defect I released. (Shame on me!) If you receive this error message when you deploy:

18:25:30,078 ERROR [MainDeployer] Could not create deployment: file:/C:/jboss-4.0.4/server/all/deploy/coffee.war<br>org.jboss.ws.WSException: java.lang.ClassNotFoundException: org.apache.cactus.server.ServletTestRedirector

this means that I left some configuration behind related to Cactus. Since I don’t include Cactus in the project, it cannot deploy properly. You can either change the file conf/coffee.war/web.xml to remove the references to Cactus or download the project archive again (by clicking the title of this entry).

I apologize for the confusion. See you at 9 AM!

We have arrived in Oulu, and are now on the hunt for some power adapters to accommodate the plethora of electronics we have brought with us. This is the one part of the trip we’ve done a poor job of planning.

So we are at the hotel. For anyone else attending XP 2006 who has arrived, feel free to e-mail me (me at jbrains dot info) and let me know whether you’re interested in getting together for food or drinks sometime in the next few hours.