Posted by Sometimes they do. Not by design or intent. But because they are showing the processing and results of new code forged by me and my team. I proclaim this crashing fact somewhat proudly because it distinguishes me from a set of folks who believe a demo is as good as a shipped product.
In December 2000 and January 2001, I spent the better part of 2 months around some friends who were readying the demonstration of IBM/Lotus Discovery Server®. It was to happen as part of the Opening General Session (OGS) of the Lotussphere Conference in Orlando. And it was awesome – showing the work of multiple teams in a unified display. When the folks working on the demo finished, there was a celebration with the mirth of a ship party.
Now I completely understand the need for demos that turn on the lights, that start people thinking about how life could be improved with the new and shiny. Because often it is improved; it’s why we develop the solutions we do.
But I’m proud that my demos crash.
Because demos are cameo. They are the face of systems that purportedly provide value. If mine crashes, it’s a bug I’ll easily fix like repairing bad makeup. I don’t try to crash, and I do prepare such that I won’t. And I work hard to fix my bugs before I ship. But if a demo crashes, it shows that I’m involved in things just as important as first impressions. There are those with whom I work who dislike that because nothing matters like first impressions to them. But if you ask them what brings sustained business, they will tell you reference accounts. And reference accounts are established through operational value, NOT through demos, although demos get you in the door.
In my recent trips to Germany I heard several detailed stories about the exorbitant cost of solutions that people had moved to from our product Domino. Ongoing costs – mostly but not only people – ranged from 100 to 300 times what had been the cost prior for the same functionality. One friend made the point that once the move had been made, it was a rare CIO or IT manager that would agree to the dissolution of his/her 300-person team. So the problem compounds culturally.
I interviewed years ago at EMC – the storage folks. Walking in their door, one was greeted with about 300 TV screens playing live video streaming from a single disk system. This was 1998, for reference so yeah, amazing throughput for that day. And once entering the building, there was a disk system without a cover being zapped by a laser (!) showing its resilience. I don’t know if that was really, but it served the effect of zapping me!
So I would that demos would show off operational costs. That they would show working, populated and scaled systems with the people and hardware costs contained and frugal. Could we do that? To me that would have the benefit of telling true stories, debunking the claims of those who live off cheap stories about compliance and bundled sales ploys to entrap organizations in expensive debacles.
I’m jaded when I hear of how easy an environment is to set up and program against; how well disparate things integrate and “just work”. Because NOTHING “just works”. At some level of scale or complexity the initial ease is eclipsed by fundamental problems. The cost is often in hardware, but much more commonly it’s in people. Many people.
Quality, economy of scale, solid integration and expandable architecture are the most valuable aspects in the end. When they’re being experienced, it’s a demo that never crashes.
J D Curtis 