I’m becoming convinced that there is a scourge in the Microsoft development ecosystem, and it’s called the 10 minute demo.  Here’s the problem:  No matter what the tool is, you have to make a demo that, in 5-10 minutes, purely using point & click design tools, shows off the power of the tool and technology.

Now, the problem isn’t that you have to get your message across in 5 or 10 minutes; I’ve found that the harder I work at getting the message down the better the message gets.  Instead, I wonder how many product managers have had to sit back and say “fine fine, but enough about what customers are telling us it really has to do:  how am I going to make a point and click demo that will go from user interface to database through any number of tiers and makes it all look easy?”  The problems that we really want vendors to tackle are hard:  If they were easy, we wouldn’t be looking for solutions.

Take Entity Framework.  This is a very complicated set of technology that’s oriented at a very complicated problem.  If you have the problem they’re solving, it can be a huge time and cost saver.  Developing a technology like this is extraordinarily expensive, and you’ll be married to it for a long time so it’s good to have a major vendor stand behind it.  I’ve been in environments where this would have cut major projects in half and eliminated piles of risk.   I can imagine the challenge the Product Manager for Entity Framework had when we had to make a few short demos that show off how great this technology is.

This is a high-concept technology for integrating disparate data sources into a common model.  Any demo you can do purely visually in 5 minutes of the product is going to be contrived at best.  Most of the demos I’ve seen have been how you can take Entity Framework and point it at your schema and then get your client to bind to it.  You know, the same thing you could do with ADO.NET, LINQ to SQL, and any number of other technologies…  And shouldn’t do.  It does a disservice to the tool because:

1. You end up walking away with an underwhelming impression of what the technology is uniquely enabling; something that you couldn’t easily do before.
2. The demo shows an approach that really doesn’t scale to real-world problems.

The last one is the real problem.  Folks who are approaching using your technology to solve real world problems take the methods you use in your demo very seriously.  They’ll pick it apart and use it as a trump card in design conversations:  ”but here’s how they did it in the demo, just strait from that little part of the UI back to the database.  So we make our huge application by just doing that over and over.  It’s how they did it!”.  I think of all those early demos of .NET that showed people dragging a few tables onto a designer, then dragging that onto a UI, click click click and *poof*, there’s the list of customers!   But seriously, would you really build anything of scale that way?  Unlikely – maintenance challenges, performance, production considerations (like common error management and security) all argue against it.

As an experienced team of developers, even we get caught by this some times – we look at the buzz and a demo around a visual design tool like LINQ to SQL and then charge out to try it on a skunkworks project.  Within a short period of time we’re in trouble with it – everything started well but now we can’t update the model, or we keep losing our changes, or we can’t get it to handle the full application lifecycle.  We’ll talk back and forth trying to decide if:

1. We just don’t get it. We’re just too old and set in our ways, and can’t see the great brilliance of the new vision.
2. The demo approach is demoware. A feature you’d only use in a demo.

In the end, we nearly always prove it’s the second.  We pick it apart, talk with other (non Microsoft evangelists) folks and come to the consensus that yes indeed the natural laws of computing haven’t been set aside by this new strategy or tool.

So please, I’m begging you – if you work for Microsoft or in the Microsoft ecosystem, put an end to demoware.  Your product may not make a 5 minute end to end sample – so show us how it fits conceptually.  I’ll get more out of your 10 minute video on Scrum that’s funny and conceptual than I will on a contrived sample that just shows that your product can solve a problem too simple to justify its use.

A final note:  I’m not really singling out Entity Framework as having bad demo videos.  There’s a lot that I disagree with about how EF was rolled out (A service pack?  Really?  How about .NET 3.9…).  They actually did create a set of conceptual videos, but the high traffic stuff in MSDN has a definite feeling of demoware.