Model Presentation:
The example for the model presentation is the one given by Richard Campbell and Kent Alstad on Scaling ASP.NET Applications. This may not be necessarily the best model in terms of delivery of technical content depending on what level and the type of projects the attendee has been on; but it was certainly a good example of a well-rounded presentation. The reason why I worded these things as "presentations" as opposed to something more interactive is because they are moreso speeches. Sure, the talk could have included some code samples and demo'ing in Visual Studio, but that wasn't the intended goal and it is after all called a TechFest as opposed to Code Camp =).
In any case, as I pointed out earlier, the presenters were very organized, focused on their area of expertise and knew how to interact with the crowd. By focusing on their area of expertise, they spoke from their own experiences and also did their homework. And because of this, they were able to provide some cool inexpensive (free) resources for calculating performance. Enter http://www.websiteoptimization.com/services/analyze/ for assistance in part of your performance equation calculation. And even though they weren't making an entrepreneurs sales pitch, they were definitely one of the better presenters at following Guy Kawasaki's Rules of PowerPoint.
The fact that Richard Campbell is a rock star in the .NET community may or may not help with the audience's perception of the presentation itself. It could help in the fact that it would draw a bigger crowd (compared to the crowds of other talks, I would so say). But the flip side of this is that the crowd may also come to expect more out of the famed (Greater) Vancouverite.
Presentation Gone Bad:
Just a quick disclaimer beforehand, the following is not meant to be offensive. It is rather intended to be an objective look at the post-mortem of a presentation. Some of the actual events for this "presentation gone bad" were a result of unfortunate circumstances. The following is intended to take away some of the things we can learn from other's misfortunes.
The presentation gone bad would be the Ruby Talk at the Vancouver Tech Fest. This was a promising talk as it was one of the few sessions that was aimed at unifying this into a tech fest as opposed to the traditional MS-backed Code Camp featuring only Microsoft Technologies. Also, for the last couple years, Ruby has been the hot poster child programming language of the open source world. Now, it was time to convince the norm folks from the Java and .NET camps of this. Well, evidence of this already began with converting John Lam, innovator of RubyCLR - Ruby for .NET, into a blue badge dude.
To start off the presentation, Nathaniel Brown experienced technical difficulties with hooking up his Mac. (Kind of puts of a damper on the whole "Mac, It just works!" motto eh?) At this moment, you may be recalling back to your college days. You know the one...the one where you had to do a demo of the term project and X% of your mark depended on it. And what do ya know? You come across a glitch during the demo that you've never encountered in test. Actually, for many and even for some of the best of them, this still happens in the real world. At this point, it all comes down to how you score in the recovery mode. So with Rob Chartier to the rescue, the presenter is able to get the presentations running on Rob's laptop.
Unfortunately, this was also where a questionable decision was made. He decided to download the famous Ruby demo on http://www.rubyonrails.org/screencasts, showing the making of a simplified weblog in 15 minutes. (NOTE: He had originally intended to code up his own "live" in 5 minutes). The reason why this is questionable is because for some, myself included, they have already gone through the screencasts and installed Ruby on Rails. I suppose part of the problem stems from the fact that the agenda only stated "Nathaniel on Ruby", making it difficult to determine what level this was for. In any case, showing a video of other's work in his own presentation did not prove to be a hit. For one, the font was way too small as it was being replayed in QuickTime. Secondly, people coming to a talk are expecting to see original content made by the expert speaker.
He was speaking in front of a primarily Java and .NET crowd. Once he realized the presentation could not go as planned, perhaps he could have modified the talk so that it was more of an open panel discussion. This would allow for mutual flow of information. Unfortunately, he was not very convincing in pointing out advantages of Ruby. For the most part, his only convincing case was that he preferred the syntax which is a subjective thing. And unfortunately, when he referenced other languages, he could not draw much from his own experiences but still attempted to justify his opinions. For example, he stated that "Having worked with PHP since PHP3...PHP has some of the best documentation support amongst all languages". Unfortunately, this is a classic case of speaking on topics outside your areas of expertise. (At the beginning of the speech, the presenter highlighted how he really only has real work experience with PHP and Ruby). I can draw an analogy to Richard Campbell and Kent Alstad's talk on Scaling ASP.NET Apps. Much like an application, a language also needs time to scale and mature. And with that is the support and documentation. What does the scaling of a language encompass? Naturally, the adoption rate and industry backing goes hand in hand as well.
Comments coming from the crowd were that he was attempting to make assumptions on other languages without speaking from his own real world experiences. Perhaps a better approach would have been to state the obvious, "Use the right tools given the circumstances". Personally, I see Ruby and Ruby on Rails as a great tool when it comes to specific scenarios (i.e. rapid prototyping, small projects, automation testing).
Some very good lessons to learn from a "Presentation Gone Bad". Not only in terms of what to look out for when presenting, but also what to consider as a technical guy.
- Come prepared and sort out technical difficulties beforehand.
- Speak on topics within areas of your expertise ONLY (refer to point #1).
- Have a backup plan (refer to point #1).
- Know your limits on technical areas.
Well, it's always easier to analyze something in hindsight and at the expense of others. But you know how the old saying goes, "experience is just having made all the wrong decisions before". So, better to learn from another's "experiences".