共用方式為

Should Evangelists Be Forced to Unit Test During Their Demos?

  • 發行項

Last year, my friend DonXML issued a challenge to me:  No more Console.WriteLine demos, from now on replace those demos with unit tests.  Jim Holmes posted about his desire to see more focus on unit testing from the evangelists as well.

Don and Jim: I’ve tried, I really have.  I haven’t been successful at it, and haven’t done it consistently. 

During PDC05, watching others present, I realized that I learned much, much more when I watched someone code and explain what they were doing than if they opened a bunch of existing code and tried to explain it.  I also found that I learned much, much more when the presenter stayed in Visual Studio and just kept creating than when they showed lots of PowerPoint slides.  I decided to say no to pre-baked demos, my demos are almost always coded from scratch.  I also try to forego PowerPoint for most presentations, instead firing up Visual Studio and create apps from scratch. 

Lately, I am starting to question what people would rather see.  Do you really want to see demos start from unit tests, even at the expense of learning new concepts?

The evals almost always have incredibly high marks with comments praising my deep knowledge of a subject demonstrated by my ability to code it on the fly, even adapt the demo to questions being raised from the audience.  This also has the drawback of running out of time or accidentally renaming something I shouldn’t have or missing a configuration switch or simply trying something in front of an audience that I haven’t already practiced.  I admit I have also become notorious for trying to pack too much into a short timeframe and trying things that I can’t fully get to work.  The guys at Disney joked when one of my demos actually worked the first time (which is why I love screencasts and blogging, because I can make edits that make it look like I was flawless in execution!)  The kind of demos I show are how to use Visual Studio to build workflows, create WCF services, develop against SharePoint… none of which can be easily unit tested or even quickly mocked.  Admittedly, some of those demos probably could have used unit tests, and probably would have avoided a broken demo or two, but I honestly have a hard time trying to force unit tests into my demos.

I recently did a talk on Windows Workflow Foundation.  I had 90 minutes to try to weave a story of why Windows Workflow Foundation is a valuable technology.  It takes time to explain persistence, show it working in a meaningful way, explain tracking, show it working in a meaningful way, explain activities, demo them in a meaningful way.  You see, I could just pull up a few samples from the SDK, explain one or two lines of code, and then skip to the next section.  Instead, I try to focus on helping attendees understand what they are seeing enough that they can reproduce the demo when they get back to their keyboard.  Most of the demos that we give these days focus on things that cause a shift in thought.  Cloud services, workflow, identity, Silverlight presentation… It’s difficult to show something that is so fundamentally different from your current way of thinking within the limited time frame, let alone try to pepper in proper coding practices.  I showed basic concepts and introduced them to an audience not already familiar with basics, and ended up going way over my allotted time (horrible, horrible, horrible, I do this way too often).  If I had mired any further with proper coding techniques, I would barely have introduced the limited amount that I was able to convey.

I don’t perceive that people come to my talks because I show them how to bullet-proof their code, I perceive that people come to my talks to learn a new concept and be entertained.  My wife tells me I am not nearly as funny as I think I am, I think that people come to my talks to learn the concepts more than be entertained :)  Am I right?  (about learning new concepts, not about the being unfunny part)

Something I have tried to take to heart is comments that I have seen in evals as well as in blogs that they want evangelists’ demos to work.  There’s the balance, because it’s much easier to make a pre-baked demo work because you aren’t doing anything other than highlighting text in the IDE and hitting F5 to compile.  I’ve since started practicing my demos and only focusing on things I know how to do really, really well, but some folks have pointed out that they learn a lot by watching me fix things in my demos. 

So the question goes to you, dear readers… what do you expect in a demo?  Shiny, flashy graphics?  Lots of animation?  Deep plumbing?  Do you like it when someone pulls up an entire working application and explains a few lines of code, or do you like it when someone codes from scratch but doesn’t achieve nearly as much as a pre-built demo?  Do you get disgruntled if the presenter tries something new and can’t get it to work, or do you like exploring new functionality in real time?  Do you expect the demo to be polished and flawless, or do you enjoy the rough edges?

Comments

  • Anonymous
    April 30, 2009
    PingBack from http://microsoft-sharepoint.simplynetdev.com/should-evangelists-be-forced-to-unit-test-during-their-demos/

  • Anonymous
    April 30, 2009
    I'm all in favour of Console.WriteLine - an example meant to teach something new should contain as little as possible that doesn't pertain directly to what's being introduced, otherwise the signal is lost in noise. People should know how to use Unit Testing and that they should do it: if not, including it in your demo isn't going to help. A real demo sin on the other hand would be for instance using a WebGet() in a WCF demo to trigger a database update: things that are actually bad shouldn't be there, but things that are just incomplete for a real-world application (especially when what's omitted is a common requirement rather than something specific to the particular technology under discussion) are normal and in my opinion necessary for clarity.

  • Anonymous
    May 01, 2009
    Thanks for adding to this discussion, Kirk! I don't have any issue with part of an overview of a technology being just flat-out demo code. That's an easy, clear way to focus on the topic at hand, nor do I expect folks to teach unit testing during presentations. My argument/hope/wishful thinking would be that after that short demo a deeper discussion hits on how we really need to use this. How do we split things out so we /can/ test? What rough edges do folks run across when trying to implement the tech du jour? How do we work with these tools/products? The overview of something's fine. Just give me as an engineer more to think about when I have to make hard choices about implementation. Again, thanks for joining the discussion.

  • Anonymous
    May 01, 2009
    Oh, by the way -- not once did I ever indicate folks should be FORCED to show tests during demos or presentations. :)

  • Anonymous
    May 01, 2009
    The comment has been removed

  • Anonymous
    May 01, 2009
    The comment has been removed