Kirk Evans is a Microsoft Architect for the Azure Center of Excellence.
Introduction to SharePoint and Azure IaaS
Building SharePoint Apps with Windows Azure Platform as a Service
SharePoint Solutions and Architectures on Windows Azure Infrastructure Services
Understanding Authentication and Permissions with Apps for SharePoint and Office
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?
PingBack from http://microsoft-sharepoint.simplynetdev.com/should-evangelists-be-forced-to-unit-test-during-their-demos/
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.
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.
Oh, by the way -- not once did I ever indicate folks should be FORCED to show tests during demos or presentations. :)
Thanks for the comment, Jim. The "forced" comment actually came from DonXML. Over beers, he said he'd love to see a mandatory requirement that all evangelists' demos involve unit tests.
Here's a thought... what if there is a campaign at the user group level that focuses on code quality and best practices? I've got to admit, as evangelists we are constantly learning new technology and barely have time to learn it before our demos, let alone have any concept of best practices. We are miles wide and an inch deep on most technologies. But the user groups have deep expertise because you code for a living, work in teams for a living, and fight code quality issues daily. Instead of evangelists (who often haven't written a production line of code in years) trying to assert what best practices are, shouldn't the user groups be the ones to present and discuss best practices?
While an evangelist absolutely should be able to demo a test passing or failing, how effective is that? Shouldn't the local user group demonstrate and discuss the impact of agile, TDD, scrum, etc on daily lives? I'd certainly attend, but readily admit I am in no position to present on those topics.
Heh, you hit on a sore spot: "best practices." I hate that term because everything depends. :D
Seriously, I'm not expecting you to teach best practices, Agile, or any methodology. Frankly, you SHOULD stay away from those.
What I'm asking for is discussion around how things should be implemented. Yes, tests would be nice in a demo, but at least show a decent design. No code in code behind. No behavior in XAML. Split all that out into a proper layered design.
Again, I think a quick run through using mashed up code is OK -- but by all means follow that up with the real world stuff.
I completely understand where evangelists are regarding distance from production code. While I don't expect y'all to change the world by yourselves, I would expect that you at least look to understanding those technologies enough to be able to speak to implementation details when talking to the technology. (I'll avoid making any parallels between evangelists and booth babes. :) )
You're absolutely right about the critical role of user groups and the broader community in this. I'm working on that end of things, or trying to.
That said, again I go back to my scalability thing. You folks get in front of SO many people that getting YOU discussing good implementation details of technologies is a tremendous benefit. You guys can also scale with partners/customers to learn a bit of the hard edges and pass those details back to the community, too.
You can't solve this issue all on your own, and I don't expect you to. I didn't expect Sun to pass on all this kind of stuff when I was doing Java work. But could you at least give a shot at helping? That's my real question.
Again, props for the discussion. That's at least part of the solution.