As I’ve started writing about public speaking, I have started getting great questions that lead to more blog posts – keep those coming! I was talking to a fellow speaker (who can identify himself in the comments if he so chooses) and they brought up the fact that it’s hard for them to prepare a demo. I can tell you that this is an art form that I still struggle with after 9 years speaking at conferences, user groups and training. Demos are hard because you’ve got two, sometimes competing, motivations behind every demo. First, you have to show someone how to accomplish a given technique and second you have to be able to show someone why that technique applies to them in a given circumstance.
There are two extremes that you can go to. You can either demo just a particular technique in isolation or you can demo a full application/solution.
Demo a technique in isolation
Sometimes this is the easiest thing to do. It requires a lot less code and it’s very easy to walk through. The issue here is that it’s like solving a numeric math problem on the chalkboard. It’s sometimes hard for the audience to connect the dots and place that technique in their own circumstances and leverage it to solve their own problems.
Demo an Application
This is tough. There are two major issues. First of all, you have to have a competed application to walk through. Secondly, and the bigger problem honestly, it’s very hard to walk through just the relevant parts of the application without getting bogged down in the full details of the application. The tendency is for people to spend a lot of time scrolling through code rather than focusing in on the code that’s relevant to the current discussion.
The right answer
The reality is that the answer is somewhere in between. It’s much better to have a well componentized application where people can see the technique in the context of a larger application but you can demo the technique without getting bogged down in the minutia of the application. I’ve not seen a lot of demos that actually do that, which is a shame because it works extraordinarily well when someone does do it.
Building the perfect demo application
At one point in time (many moons ago when I was doing a ton of ASP.NET talks at conferences), I had a built a relatively full featured ASP.NET 2.0 demo application that I used for all of my ASP.NET talks for about a year. It was based loosely on a portal application that I had built for a client. It used themes and skins, user profile information, a little AJAX, user controls, custom controls, login in controls, databinding and much more. But it was built in such as way that it could be demoed feature by feature.
The secret sauce was that I had just enough examples of each technique and it was broken out into many small and manageable projects and files. I could show each of these small files and projects in relative isolation but then show it running in the overall context. My user control demo, for example, was a very simple “Hello World” style button and label but it showed how to build user controls. My personalization demo stored 3 fields and used them in two places. Why two places? Because we needed to see what refresh was like and so on. Why three fields? One was set in a custom step in the login control (because I needed to demo that). The second was to show a technique around defaulting values. The third was used to show how to move a value from an anonymous profile to a full fledged one when someone registered and/or signed in.
This was not an easy demo application to build but it was a great one because it struck the right balance of isolation and in situ so it was easy to walk through and still showed the context of where and how to use it.
This is even harder when trying to build for a technology that you’re not comfortable with. In a previous post, Prepare Yourself To Give a Great Talk, I mentioned that people can stretch themselves and give a talk on a topic that they don’t have completely mastered. This is always going to be the case with emerging technologies (Such as technologies that are in CTP or early Beta), but it can even be true with existing technologies if you haven’t spent a lot of time with them. Actually, I think this is a great way to force yourself to learn a new topic.
Two examples of a stretch goal paying off
Jeff Hunsaker recently did a talk on Entity Framework at Central Ohio Day of .NET. He learned a ton about the topic and gave a good talk. He’s been very critical of himself since then, but all reports I have heard was that he was fantastic. That’s a technology that’s in CTP and there are VERY few people well versed in it at this point. It’s hard to even get help. I didn’t see his demo, so I can’t really comment on it but he did tell me that this was a tough thing to pull together.
When I got a speaking slot at eRubyCon, which I hope to see you all at this year, I was thrilled and panicked at the same time. I knew Silverlight, which is what my talk was going to be in, but I wanted do my talk with Silverlight running on Rails so I had to learn Ruby and Ruby on Rails and put together a talk. I set about writing a demo application to learn the technologies and that helped me write my talk. I wrote a simple motorcycle sales showroom application in Rails and front ended it with Silverlight. It was a fun demo to do and it showed just enough Rails and Silverlight integration that everyone knew that I hadn’t faked it. Little did they know that I had only been playing with Rails for about 2 weeks.
I’m working on building that comprehensive of a demo for Silverlight 2, WPF, WCF, Entity Framework, ADO.NET Data Services, ASP.NET MVC Framework and more. Already you can see part of the issue. There’s too many technologies to demo so we end up trying to isolate each of the technologies in a small demo so that we can explain it easier. The issue there is that people lose sight of the integration and the workflow of the different technologies.
I’m not going to lie and say that this is ever going to be cake, but I will say that it becomes easier as time goes on. Creating decks, demos, preparing, movement on stage, delivery and all the aspects of becoming a great speaker take work and practice. Like the guy juggling, the more you practice, the easier it becomes. However, this is juxtaposed with the desire to do harder hitting, meatier talks and demos.