The Anatomy of a Demo
As of December 2011, this topic has been archived. As a result, it is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Internet Explorer, see Internet Explorer Developer Center.
March 12, 2001
Some of you programmers out there have it pretty safe. You sit comfortably at your desks, writing code against well thought out specifications. There are milestones laid out carefully before you that clearly identify the functionality that all team members are driving towards. At certain times in the development cycle, you enter what we call a "death march," where schedules are at risk, and it is, of course, expected that everybody will work late into the night, as well as on the weekends, to make the schedules. The trail you are on, however, is usually cleared out in front of you. You know precisely where you are going, and what it will take to get there.
There are others out there who code in a totally different arena. These are the guys who design and develop code that is only going to be used as demos, or prototypes of what is being proposed as a software solution to develop. Not every company does this type of development, nor do they need to. But it definitely takes a different breed of programmer to do this sort of work, as well as a different approach to this type of programming.
I'm not just talking about demoing in front of an audience the features of a finished, or nearly finished, application. I'm talking about the design and development of a demo before much development at all has been done on the "real" product. Such demos are used to show to management, partners, or investors the "potential" of the application or technology that is being proposed.
Working in a GUI/Web-based environment, everything, at some point in its cycle, depends heavily on what it "looks" like. And when a demo is needed in order to spark interest and build excitement, the visual appearance of a demo is often the key to driving the point home.
Imagine demoing a PC connected to Home Automation. Your application has a button on it that says "Turn Off Lights." You press it, and a light goes out. Yeah, a real yawner. Now imagine that the demo is done with a PocketPC, on the screen is an overhead layout of the house, with indications of where the lights are. Using "Drag & Drop" the demoer selects several lights from around the house, and drops them onto a virtual switch on the PocketPC screen. He then taps the virtual switch on the screen and all of the selected lights go out. He then drags the virtual switch and drops it on the iconic representation of a switch in the room. He walks over to that switch and flicks it, and the lights all come back on. Ok, still a simple demo, but much more visually impressive then the first one. Technically, the demo really didn't change much at all; it was just the manner in which it was presented, and the props being used to carry it off.
It is important to note that with our little automation demo what was shown was not representative of how the system would normally be used. I mean how many people want to turn on and off lights by having to turn on their PocketPC, look at a map of the house, select the light, drag them to a button on their screen, and then push that button? In reality, such a tool would be used for a very short period when the automation system is first installed in order to "program" the physical light switches in the house, and then rarely used after that. But how exciting would the demo be if you just walked over to a physical light switch, flipped it, a light went on, and you told your audience "Trust me, it was through home automation that this light was connected to this switch."
It takes a slightly different type of programmer, and a different mindset, in order to work on prototypes and demos like this. It often starts with a demo script, which is simply a description of what you think a compelling demo would look like. Perhaps you mock up what a few screen shots might look like using something like Adobe PhotoShop, or Microsoft PowerPoint®. This allows you to get the ball rolling and help the others on your team grasp the overall concepts that the demo needs to address. Next, you write a little bit of the underlying technical infrastructure, just enough so that you can plug some of the components and functionality together. Next you work on building up the visual interfaces that you want to use, making them as visually appealing as possible.
One of the harder parts of this process for many developers to understand is that they are rarely working against a cleanly defined technical specification. They aren't working on building a stable and well-architected infrastructure that is intended to work flawlessly for years; instead they are rapidly trying to piece together just enough real code to sit beneath a fancy façade so that the demo can be as realistic as possible.
The timelines for these demos can often be brutal as well. It is common for a demo scenario to be laid out that needs to be developed for presentation at an event that's only weeks away. The implementation team quickly assigns tasks in order to make this deadline, and while they are doing this, their manager comes in and informs them the company's VP was so excited by the description of the demo that the manager gave, that the VP wants to see it next week. And then later on that day, the manager comes back in and says that the CEO will be meeting with his staff the following day and wants to see the demo in order to plan for how to position it along with some other technologies that are being developed. So what was once a two week timeline, which was already an aggressive task, has suddenly be narrowed down to only 24 hours… life in the fast lane.
But perhaps the hardest part for developers to deal with is that at a moment's notice, the entire demo can be changed, or even scrapped entirely. By their very nature, these demos need to be fast paced and dynamic. The scripts and scenarios on which they are based will change, often radically, from one day to the next. As the developers are working on breathing life into the hastily scrawled out concepts, their management is often brainstorming with others on how to make these demos more and more compelling, and how to best illustrate the underlying technologies that they are planning to develop.
Now, imagine that you have made it through all of these hurdles. You and your team have built up a very exciting demo that actually includes connectivity to some of the underlying technologies. Throughout this process, you likened yourself to Chief Engineer Scott from Star Trek, getting the warp drives back online during a battle with the Klingons by bleeding off power from the transporters and routing it through the dilithium crystals. It will hold, but just barely. Now the real test comes when your demo is presented to the executive staff to see if your project gets the staffing and funding that is necessary in order to bring it to life.
Let's assume that the demo goes flawlessly, not only does the demo scenario itself that was worked up grab the audiences attention, but you even prepared for some impromptu functionality that might be needed, and sure enough some of the questions you anticipated are asked, and the demo is able to show how the queried situation would be handled. This could be considered the perfect end to weeks, or sometimes months, of long hours, hard work, and countless redesigns.
The problem often faced in situations like this is that the demo is too good. It appears to work so well and depict the proposed technologies to such a degree that the audience expects that most of the work has already been completed. They can't comprehend why you need two years and four times the staffing and budget to finish a program that only took you three weeks to develop and appears to be 80 percent completed.
Sometimes, life just isn't fair.