I participated last night in The Sword Experience. This is a delightfully fun event organized as part of Microsoft’s annual “Giving” campaign, and I was very happy to donate to support a great cause and spend 3+ hours pretending to sword fight with actor Adrian Paul^[1] and a bunch of like-minded Microsoft employees.

I can’t wait to do it again, but there were a few things that bothered me, especially when Mr. Paul “corrected” my footwork during some of the warmup exercises. I’ve spent much of the last four years studying various historical martial arts^[2] and practicing them as a full-contact combat sport, and footwork, balance, and structure are the foundation of all of that. Damn it, man, I know how to do this the right way, and you’re trying to make me do it wrong!!

Sigh.

Of course I didn’t say this, and of course it would have completely missed the point if I had. The event was about stage combat and fight choreography, not about actual sword fighting. Even though the two things may look the same from a distance, they have fundamentally different goals.

And this got me thinking about software demos, and how they relate to building production software. These things look similar from a distance as well, but they also have fundamentally different goals.

In an actual sword fight, you want to make small, fast movements that can’t be predicted, and which make contact before their threat is recognized. You want the fight to be over immediately and decisively. In a stage fight, you want to make large, easily visible movements that are clearly expressive of threat, but which are not actually presenting one. You want the fight to last for a long time, and to be interesting to observe.

When building production software, you want to make a solution that is secure, that performs well, and that is easy to maintain and extend. The structure of your solution, and the processes used to deploy and support it, reflect these goals. Typically you do not optimize production software around its ease of understanding, and instead invest in training new team members over time.

When building a software demo, you want to make a solution that is easy to understand, and that communicates and reinforces the concepts and information that are the foundation of the demo. The structure of the demo is simplified to eliminate any details that do not directly support the demo’s goals, even at the expense of fundamental characteristics that would be required in any production system that uses the concepts and technologies in the demo.

A demo tells a story that reflects the reality of a production system, but deliberately glosses over the complicated and messy bits – just like a choreographed fight reflects the reality of an actual fight, minus all the violence and consequences.

You can learn from stage combat, and you can learn from demos. Just don’t mistake them for the real thing.^{[3] [4]}

And now it’s time for me to go cut something with a real sword, just to make sure the things I practiced last night don’t stick around…

Isn’t that a sight just overflowing with promise? Like an empty Visual Studio solution, where anything is possible…

---

[1] Yes, the guy from the Highlander TV series. That guy.

[2] For a great introduction to this topic, check out this short video. This video is how I discovered that HEMA was a thing, and I never looked back.

[3] I was hoping to incorporate the YouTube trope “will this martial art work on the street??” into this post somewhere, but I didn’t find a place where it fit. Maybe next time.

[4] In both situations, don’t be “that guy.” Don’t be the guy who complains about how a demo isn’t “real world” because it isn’t production ready. And don’t be the guy who complains that the stage combat moves you’re being shown aren’t martially sound. Seriously.