Writing software is hard, particularly when the schedules keep programmers “nose to the grindstone.” Every so often, it's important to take a breather and look around the world and discover what we can find - ironically, what we find can often help us write software better.
Frequently, developers are asked to estimate around technologies they do not understand well enough to estimate (regardless of whether that estimate is about time, or money, or difficulty, or…). But history suggests that prototypes are a dangerous path to tread.
Almost every geek knows the scene: Luke Skywalker and Obi-Wan Kenobi, having just escaped the Imperial Stormtroopers seeking to find their newly-acquired companions, R2-D2 and C-3PO, are blithely zooming through space when Kenobi, the Jedi Master, puts a hand to his head and says those fateful words: “I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened.” Which, of course, corresponds directly to the planet Alderaan experiencing a pretty severe heat wave (in the form of a planet-cracking superlaser).
Developers are pretty sensitive to the Force, too.
Don't believe me? Consider this story: a young developer, new to the ways of the Source, is asked by his management, Darth Serious, to create a “quick and dirty prototype” for a project. (You start to feel the shivers down your back already, don't you?) The young developer goes off, uses the Source, and returns with the prototype. (It's like a Stephen King novel for programmers.) Management sees the prototype and proclaims, “Amazing! You have built the app when all we asked for was a prototype!” (You want to scream through the pages to this innocent developer, warning him of what's to come next, begging him to run for the door while he still can, but alas…)
“Ship it!”
("NOOOOOOO!!")
And all over the world, developers suddenly put a hand to their head, and feel the great disturbance in the Force, knowing that something terrible has happened: another prototype has been deployed to production.
Prototypes
The need for prototypes is pretty clear: We don't want to use something if we can't tell whether it will be effective, but we won't ever know its efficacy until we use it. Thus, we reason, if we sort of build the app “in the small” using the new tech, we can get some of that experience that breaks the chicken-and-egg cycle, obtain the information and experience we need, and then get to the “real” development. After all, everybody knows that “you always throw the first one away”, right?
Unfortunately, apparently nobody told management that. They look at the prototype, they see working software, they do what anyone would do: “Ship it!” We try to tell them that it's a prototype, not ready for production, but they don't seem to get it. When did prototype mean “something ready for production”? At the risk of mixing my geek metaphors, every time this happens I feel the temptation to quip off, in my best Spanish accent, “You keep using that word. I do not think it means what you think it means.”
We can't abandon the prototype (or proof of concept, or research spike, or whatever else you want to call it). So how do we manage a prototype successfully?
Successful Prototypes
Jesse Schell, author of The Art of Game Design, has a great list of rules regarding prototypes in game design; not surprisingly, these points also work pretty well for non-game-related prototypes, too:
As a corollary to this, if the question being asked is around technology (“Will this scale?” “Will it perform?” "Will it work?"), then make sure the prototype is nowhere near the business domain. Look for problems that, on the surface, have no relationship to the business' domain, and model those. If you work for a financial services firm, build a prototype around scheduling out a technology conference, or around reading quotes from Twitter, or on how to model bird-flocking behavior, or anything else that strikes your fancy, so long as it has nothing to do with financial services. Remember, if this prototype is about exploring a technology, then this prototype's job is to find out if a technology will work, not to explore the business domain. The less this prototype looks and acts like the domain, the less likely it will end up getting shipped.
There's probably a few other lessons we could add to this list - your experiences here will help flesh out this list within your company further - but this is a pretty good place to start.
Prototype Away, My Friends
Prototypes remain a powerful tool in the developer's arsenal, but given how shallowly most management, customers and users can see into the software (all they see are pretty pixels, and if the pixels look right, then everything else must be right too, right?), we as developers have to “manage” the prototype project almost as carefully as we do the “real” project.
Get too careless with prototypes, and suddenly, that giant planet-cracking superlaser is aimed at you, and you become an “object lesson” for the rest of us.
And that would kind of suck.
