I’m not sure if that is a real term or not, but I have a rather specific meaning for it:
A completely useless feature added to a product because it makes a good demo.
Let me first say this: I reject as false that there is some type of dichotomy between features that look good in a demo and features that have great utility. Of course, at a very important level, it matters entirely who your demo audience is.
We’re going to take a side-trip down memory lane for a minute, and by “memory lane” I mean “things that I have no memory of, since I probably wasn’t born at the time, but it sounds more fun to speak of it like that.”
IBM is a services company. IBM has always been a services company (despite what anyone may tell you) – even when IBM “sold” computers to companies, they were actually leasing computers and other machines to corporations. When you bought an IBM machine, you bought into a complete package of equipment, servicing, training, etc.
The most interesting thing to me about IBM, however, is that the people who ended up using the machines day after day weren’t the ones making the purchasing decisions. I suppose that makes sense at some level, which is that a company should standardize on some piece of software or equipment and that there are many important factors in a purchasing decision that perhaps the people directly using it aren’t well qualified to make (cost, servicing, support, things like that).
It is from this time that we get the adage, “nobody ever got fired for buying IBM equipment,” and this is because IBM sold well to upper management. As my old professor Sidney Marshall told it, IBM would find the team that was actually going to use the hardware and then go sell to their bosses.
The outcome of this is that people would make purchasing decisions based not on technical superiority, utility, or even cost, but on the fact that the decision would bode well with their bosses, and would look good on paper (since IBM was a known and respectable name).
So let’s say you work for IBM around this time, and you have some new piece of equipment. Imagine, then, that you have a month left of development time, and you get to pick from the following three things for the hardware engineers to work on:
- Late in development, your testers discovered that the machine omits a horrible odor that, after hours and hours of exposure, causes faint nausea (subsequently, two of your testers quit and vowed “never to get near one of them infernal machines again”)
- The punch card reader tends to completely devour and destroy about 1 of 100 cards. It’s not a huge time waster, because the card tends to be still readable after it is destroyed, so it is easy to recreate and rerun that batch. It is, however, incredibly annoying to the testers who are operating the machine.
- The case of the machine is partially open, and shows a somewhat unpleasant view of the internals. The upside of this is that it is easy to get to components if you need to. The downside is that there is a gap in the shiny metal exterior.
You or I, as people who truly care about the quality of our products, would probably concentrate on the first two. The first isn’t anything that is measurable, so it is somewhat hard to justify in a world that values most that which is easiest to measure, but you know it would make everyone who uses what you create hate you more and more each day.
The second, when measured, appears to be a very small problem (1% is small, right?), though you find out quickly that it is a gigantic pain in the ass (over some threshold of bearable). The metrics don’t real hold out when compared to the real world “experience” of the thing, in this case.
And the third? Well, yeah, I guess it would be nice to cover that stuff up, but there’s a certain utility to leaving it open, and it doesn’t really matter what it looks like when it’s tucked into the corner of some air-conditioned room in the bowels of a building, right?
You and I, dear reader, are of course wrong.
You see, the people who are going to see the product are a) not going to use it for more than 10 seconds, so won’t smell anything (plus, you’ve decorated the inside with air-fresheners to make the demo more palatable), and b) are only going to run 10 cards, and therefore are extremely unlikely to see a card eaten. However, they are going to c) look at the machine, and notice that the insides just look kinda unpleasant.
So you spend a month working on C, to the detriment of actual usability and so the people you are going to demo to get tricked into thinking that your product is somehow better because of some time you spent on making something that effectively served no purpose except to be used in a demo.
Kinda like the default magnification thing going on in the dock on OS X – I don’t think it has any real utility, besides showing that OS X can do pretty hardware accelerated graphic funkiness. Or like any application that has a gratuitous animation that actually slows down use of the product, and only serves to show off the fact that you can do something with your new framework (just because you can, doesn’t mean you should).
Take silverlight as a good example of that – every example of silverlight I see has some control being bent, twisted, spun around, and otherwise toyed with. “To what end?” we should all ask; I’ve never felt the desire for any control on any of the webpages I use (or even desktop apps) for things to be turned facing away from me and still interactive. I don’t think a window is that useful that you can still use it when it’s been genie’d like when minimizing a window in OS X.
“But, but, look what you can do in this WPF-esque thing! It was only 2 lines of xaml!” Guess what? I don’t care that it was easy to do. I don’t care how “powerful” it is, or that it is impossible to do in plain ol’ html.
If it has no actual utility, it has no place in your app.
And if it wasn’t clear from my story earlier, keeping your software from smelling like shit does count as utility to me. Utility is not correlated to the number of features or the (necessarily) the raw speed of your application or the bazillions of pixels you can spit out to the screen every millisecond. I like the much more hand-wavy “experience” test, which is to see if you enjoy the experience of using the application.
It’s kinda like buying a car, I think. There are lots of important things to look at when buying the car, but everyone I know seems to take as obvious that the most important part is the test drive, getting to actually use the car for a little bit to get a feel for the car and see if you enjoy the experience of driving it.
You can’t easily or often times meaningfully measure the “experience” of the car – you can certainly ask people to rate their experiences on some scale, but I doubt that’s an easy thing to predict (until you’ve been making essentially the same car for decades, in which you have a pretty good understanding of what things people will enjoy), and it certainly isn’t as easy to measure as horsepower.
And that is the great trap I see some people fall into: the desire to devote time to things that have no or even a negative impact on a piece of software because they look cute in a demo, even though the software and users of that piece of software will be paying the price for it in the end.