Today was my first of four (!) scheduled training sessions with Richard Klees. Richard is hired by Microsoft to train presenters for most of our conferences. He and I go way back, and every year I both look forward to and dread my time with him.

I got schooled today, big time. While the content of my keynote and session is good, the enthusiasm wasn't there and I was doing a LOUSY job of building up to the key points in my content. He gave me a well-deserved tongue lashing!

I've got two days to get that sorted before round two on Thursday afternoon. Then one more next week, and one more hour onsite before the keynote. It's like hiring a personal trainer to get back in shape after a winter of over-eating *grin*.

My 3rd dry run in front of all the keynote participants went well. I ran 11 minutes, so I still have 3 minutes of fat to trim. But the technical pieces worked fine and the content is in the right order.

Tomorrow morning I work on shaving 3 minutes off, and then next week I start with automation!

I just finished running through the demo for a couple of my PMs, and aside from the fact that Visual Studio hung in the middle, it actually went really well. They gave me great feedback on the content, and I'm much more comfortable with what we're showing. It flows well, and the story behind the application is coming together. I also changed from using a datagrid for the application to actual controls, which makes the application look at whole lot better.

As for the hang, we figured out what that was too, and I know how to prevent it next time through.

Dry run #3 is tonight at 5pm. Dry run #4 is tomorrow afternoon for BillG's speech assistant. Eep.

Last week I wrote about the process of selecting a build for the keynote. I had high hopes for 50401. Those hopes were dashed today when I got the dialog below. Sigh. This dialog shows up a random period of time after messing with some of the database features in Visual Studio. As you can probably guess, having a dialog that randomly shows up that you can't get rid of is a Very Bad Thing during a keynote demo.

I thought 50401 had the fix for this issue, but it turns out that I missed it by one build. Now I'm in the process of wiping my laptop and installing 50402, which will have the fix and (fingers crossed) will be the right build to use.

One of the tricky things about a keynote demo is you want it as focused and crisp as possible. We spend a lot of time making sure the things we say during the demo are short, to the point, and easy to understand. But that's only half the battle: the code has to be concise too.

Any code you have in your application that does something is a potential failure point during the demo. Code that's in your application but isn't actually part of what you'll be showing is scary stuff to have. One funky nervous jitter of your hand during the demo and you could trigger that code and cause something to break.

A good example of this happened during my practice session today. We have a feature in Visual Studio 2005 that helps auto-generate UI for device database applications. Our plan was to show this during the demo, but it not only creates nice UI for looking at data, it creates code and UI for adding new records. During my dry run I accidentally hit the auto-generated "new record" menu item, throwing my demo totally off track. To make matters worse, when I tried to recover, I wound up going through an auto-generated code path that caused a (correct) exception to fire. This is bad, bad, stuff to have happen during a keynote.

So the auto-generate UI portion of the keynote is cut. It's a great feature that we'll demo elsewhere during the conference, but for a keynote it's far too risky. Too much code, too many potential failure points, and to be honest it's too hard to explain clearly in less than 8 minutes to a large audience.

Yoinks.

There's a reason why we do dry runs this often and this early before the keynote. That's because stuff doesn't work the first time through!

It turns out the build I selected has some nice perf issues in certain key scenarios. I spent some time this afternoon figuring out how to pre-build certain pieces of the demo to get around the performance problems. That was actually relatively easy. The hard part is getting the banter down and speaking S L O W L Y.

During the dry run today I made it through all of my code pieces and all the of technology demos. It was good to do a complete end-to-end run through, as the way some of the demo was laid out didn't make sense when I went through it.

We're now stepping up to twice-weekly run throughs. Tuesday next week is the next one.

Tonight from 5:30-7:00pm we're doing our second dry run of the BillG keynotes. During this dry run we're supposed to do a complete walkthrough, where we write all the code and everything. I'm just a little worried, as the Code Room taping and World Curling Championships mean I haven't had any time to spend on actually building my demo app. Add to that that we're still debating how to show some of the new developer features in Windows Mobile in my app, and that all adds up to my face looking something like this right about now:  .

One of the hardest parts about preparing for the BillG keynote is selecting a build of Visual Studio to use. Ideally I'd use Beta 2, but the reality is that Beta 2 has bugs in it, and some of those bugs will impact the demo on stage. When you only have 8 minutes to show things you can't spend time illustrating workarounds or waiting for a feature whose performance in beta 2 is a little, ah, slow.

Selecting a build is very tricky business. Amit has a post up over in our VSDTeam blog from a few months back that tries to explain our hideously complex build system. My challenge is to find a build of Visual Studio that comes out of our build lab that has the fixes I need in it for device development, but that also has stable features from other teams.

I'm helped in this quest by the occasional sanity result mails that our test team sends out. They have a specific list of tests they'll run on builds that verify basic device development features to help us get a feel for build quality. I can also talk with the tester that produces the report, to get his own gut feel on the build. Then, of course, I'll test, test, and test some more.

My laptop is installing build 50401 right now, which looks like it'll be the magic build. It is fairly recent, and is just before we started a two-part check-in that hasn't completed yet and broke some emulator deployment scenarios.

Today was quite the experience :) I attended my first real filming of a Microsoft video where more than my hands will be on-camera (my hands had a cameo in The Developer, show at MDC last year). This was filming of an episode of The Code Room.

I can't spill too many details about what is going into the actual episode, but the filming was INSANE. I was in the intro/education stuff, then got to sit backstage while the actual coding went on. We were on the edge of our seats the whole time the crew was coding/taping. It was like a big usability study where you're sitting behind the one-way glass going "MY GOD! WHY ARE THEY NOT SEEING THEIR PROBLEM!" *laugh*.

Kudos to the camera crew who lugged around cameras on their shoulders for five+ straight hours of filming. Someone should buy them all a 30 minute back massage. They're going to need it!

I took a few photos with my Smartphone of backstage, but sadly I had to hard reset my phone so it could be used in part of the filming mid-stream. I managed to save one photo, though, which is attached. It shows two of the six monitors we used behind the scenes to see what was getting filmed.

After this episode is out in the wild, I'll post a few more entries about things that happened backstage.

Today I took my first step to ensure a flawless demo at MEDC.

Internally we do a ton of automated testing of Visual Studio. Rather than force testers to manually go through the same test cases over and over when new builds come out we invest a huge amount of time in building easy ways to automate the verification of builds. You can basically use Visual Studio to write applications that drive Visual Studio UI. There are entire class libraries built by our test team to automate poking at pretty much every UI element you can think of.

I'm going to automate the entire BillG demo using our test harness.

Then I'm going to run it on the demo machine. Over and over and over and over and over and over and over and over and over and over and over and over and over and over and over.

Hopefully this will uncover that funky one time in a hundred where for some reason something goes bad. Then we'll be able to figure out why, debug it, and make sure it doesn't happen live during the keynote.

The trick is to build automation that drives VS exactly the same way I'll be doing on stage. If I plan on dragging and dropping a control from the toolbox that's what the automation has to do. It can't double-click to add the control, as that's a potentially different codepath than what I'll be doing. I'll probably build two versions of the test as well: one that runs as fast as it can (so I can get lots of runs in) and another that is timed exactly to our demo pace so I can unearth any potential timing issues. Believe it or not, we've had bugs that repro only if you do something, wait 5 minutes, and they try to do something else. Man, those are a pain to figure out. But I digress...

The tricky part will be figuring out how to automate the application once it is running on a connected device. I know the mobile device guys have automation too, so I'll probably have to talk to them and find out how their automation goo works. Sadly I'll probably have to test the desktop piece separately from the completed device app, but at least I can be pretty confident that everything works.

More will come on how to ensure a flawless demo as I uh, figure out other ways to make sure there's no problems :)

Well, sometime over the weekend I got a meeting request from James for a meeting today at 5:00pm to do a walkthrough of the high-level talking points for the keynote demo. Pretty fun stuff considering I just got all this on my plate on Friday, and spent the weekend curling. Ah well, it makes life interesting.

Thankfully Ori and James had already sketched out the idea for the demo, so I hacked together a rough outline of the talking points. The runthrough went smoothly, and now I just have to figure out how to make it fit into 8 minutes and include two other features. Yoinks!

Between now and next Wednesday when we do another runthrough I have to:

• Firm up the script
• Figure out how to get the two other features in
• Time the demo to see how far off 8 minutes I am
• Actually go through the technical steps (right now I just have babble) and document them all
• Build a database for the application (sorry, no hints on what the data will be!)

Phew! I'll keep everyone posted on how it goes.

Last Friday Ori, my manager, stopped by my office. He's been pretty busy lately and was wondering if I could take over one of his MEDC duties. I (foolishly?) said yes, and now I'm demoing on stage with BillG during the keynote.

This blog just got a bunch more interesting :) In addition to blogging about my regular session at MEDC and other fun at the event, I'll be blogging a bit about what it's like to prep for a BillG keynote demo. As you can probably imagine it's like no other demo prep I've ever done.