Bad Demo

If you have been in the software game for any length of time, you know what it’s like to give a bad demo. You get in front of your audience and your chest puffs up as you are about to show off the killer app which you are convinced is about to trigger ear-piercing applause.

And then everything goes to shit!

As you sweat it out in front of the crowd to the deafening sound of boredom and irritation your thoughts switch to saving face as quickly as possible. You zone out everyone and do everything in your technical power to revive this spontaneously jaded bitch of an application. You lose track of time, and as your counterparts attention wanes, they start filing out of the room.

The room is nearly empty after half an hour of fruitless tinkering and you know you can’t save face at this point. Just before you slide from step 1 (Denial) to step 2 (Anger) of the grief process, you politely provide a bullshit excuse as to why the app won’t work at that moment and bring the “demo” to a close. As you pack up your laptop and projector, you try to force yourself through step 3 (Bargaining) and race right to step 4 (Depression). You dabble with the thought of drinking yourself into a coma but in the end, being a tech-head, you know you have to find out what the hell caused this. As you Skulk back to your office/cubicle/coffee-shop, you imagine all the possible causes and/or people that are likely to blame for your descension from grace.

It ends up being 1 line of code… it always ends up being 1 line of code. And not just any line of code either! It’s the line that if you were teaching a 5-year-old how to program, they would pick it out using the same logic they use when watching Sesame Street (one of these things is not like the other).

After a quick jaunt back to step 2 (Red-eyed-Anger), you can finally move onto step 5 (Acceptance). It’s not happy acceptance, but acceptance none the less.

As you can probably guess, I ran into this problem last night while trying to demo some software to a group of potential clients. Being a person who suffers from persistent mind-numbing self analysis, I have found the last 24+ hours to be an infinite loop of “How can I avoid this in the future?”. The predominant answer to many who encounter this, and live to tell the tale, is “test the hell out of your software before the demo”. The problem with that answer is it doesn’t always line up with the actuality of the world we live in as software developers… especially those of us trying to conform to Agile/Lean/Extreme/etc development practices.

Thankfully I’ve been reading the book Rework by Jason Fried lately and happened across the section entitled “Welcome obscurity” this evening. In it he states that when your company is at its smallest (as mine is currently), you can afford to make mistakes and take chances. The scapegoat in me loves this commentary simply because it means I can write-off looking like an A-hole in front of potential clients. The forward-looking developer and businessman in me likes it because it supports my desire to innovate and be creative.

Taking Jason’s comments to heart also means that I need to come to terms with the fact that I’ll likely put myself at risk of looking like a putz again in the future. Perhaps I can change those rules of engagement and focus on dealing with even smaller groups in these early days. Although that might fly in the face of my exhibitionist nature, it does come with the benefit of not having to lug around a projector.

Crisis + 28 hours and I’m feeling much better. I’ll live to do another demo another day, and thanks to Jason, my liver will too.