You've likely heard of Easter Eggs - those undocumented features developers like to throw into software. (I once coded a search box for furniture to respond to a search for "John Paul George and Ringo" with a pop-up said that said something like "Yeah, I wish they'd get the band back together too.")
I don't have a huge problem with a few small Easter Eggs in small corners of the application. I mean, I wouldn't want one in my embedded heart monitor, but overall, if the developers are competent and careful, there isn't a ton of risk.
But that's not quite what I'd like to write about today. Instead, I would like to write about M&Ms; specifically, brown M&Ms, and Van Halen
Yes, Van Halen, the rock group. You see, rock groups are famous for creating demands on the people who will host them -- not just for the space, the chairs, the lightning, electrical and equipment, but down to the size of the dressing room, the time typen and availability of the food, etc.
Among demanding bands, Van Halen is known as the chief -- in 1982 they had a fifty-three page
"rider", or stage contract, including a demand for a bowl ful of M&M's, none of which could be brown.
Keep in mind, you can't buy brown M&M's in the store - you can only get assorted varieties. So in effect, Van Halen was demanding that the host have some buy several bags of M&Ms and sort them into two piles (brown and non-brown), taking the non-brown ones and using them in a bowl. (This is a true story; check out historical reports here and here
Wow. What a bunch of jerks, right?
Well ... not really. There was a method to the madness. Snopes.com explains it this way:
The M&Ms provision was included in Van Halen's contracts not as an act of caprice, but because it served a practical purpose: to provide an easy way of determining whether the technical specifications of the contract had been thoroughly read (and complied with).
They go on to quote from Van Halen's Autobiography:
Van Halen was the first band to take huge productions into tertiary, third-level markets. We'd pull up with nine eighteen-wheeler trucks, full of gear, where the standard was three trucks, max. And there many, many technical errors; whether it was the girders couldn't support the weight, or the flooring would sink in, or the doors weren't big enough to move the gear through.
The contract rider read like a version of the Chinese Yellow Pages because there was so much equipment, and so many human beings made it function. So just as a little test, in the technical aspect of the rider, it would say "Article 148: There will be fifteen amperage voltage socks at twenty-foot spaces, evenly, providing nineteen amperes ..." this kind of thing. And article 126, in the middle of the nowhere, was: "There will be no brown M&M's in the backstage area, upon pain of forfeiture o the show, with full compensation."
So when I would walk backstage, if I aw a brown M&M in that bowl ... well, line-check the entire production. Guaranteed you're going to arrive at a technical error. They didn't read the contract. Guaranteed you'd run into a problem. Sometimes it would threaten to just destroy the whole show. Something like, literally, life threatening.
Meanwhile, Back In Software
I've worked with a lot of technical teams that communicated in writing. I've seen a lot of specifications and requirements that were dull, boring, and monotonous, and I am sad to say, some others that were much better quality that were simply never read by anyone on the technical staff.
Say you work at a company that relies heavily on written communication to get a shared understanding of what to build. Imagine putting a crazy requirement into the spec, on page eleven. In the middle of a deep technical conversation, suggest some sort of easter-egg -- when the user hits Control-Alt-Four, a picture of the entire product team appears on the screen.
If the developers complain this was a waste of time, well, at least that tells you they read the spec. If they send an email arranging a product division company meeting, it tells you they even have a sense of humor.
If, however, they deliver the product to test, you press Control-Alt-Four, and nothing happens ...
Check the line. Nobody read the spec.
At Socialtext our software has a built-in feature that allows clients to customize the user interface of the Desktop Application. Last week, our release manager changed our internal beta, so out of the box, the "what are you working on" box is pink
This did not look right to me, and I asked about it.
Guess how many people asked about it vs. how many shrugged shoulders and did nothing? Hint: Too many of the latter.
The point: Consider injecting an obvious defect into your beta program in order to gauge the effectiveness of the beta. After all: What value is a beta project in which the customers see bugs, shrug, and don't report them? (If you don't have a diagnostic like this, and add one, be prepared to be disappointed with the feedback you get. Then take action to fix it.)
A final thought
At the Grand-Rapids Tester's User's Group Last night, we spent a fair amount of time talking about specifications and requirements. One of the things we had some consensus on is that when people say "We need to improve our requirements", they are often talking about improving the way the group communicates and collaborates -- and the documents are secondary.
For a quick litmus test of adherence to spec, yes, consider a "No Brown M&Ms" test - especially if you have highly complex business logic in that specification.
At the same time, if the team just isn't talking to each other enough, your team might be better served by getting folks to talk to each other and work together
, instead of making sure they documents are read, ya know?