Joel Spolsky talks about how ineffective software prototypes are and how paper can help. The truth is that the guys at the helm can't make informed decisions with a bunch of paper. They like to see drags, clicks and resizes -- even if it's smoke and mirrors. Paper is good for small stuff, but who wants to shuffle through a ream to "see" a demo? blah

What's happening is that the prototype starts as a great idea in someone's head. Once a few people like it the software comes together from 20 different people's ideas and a roll of duct tape. Then management is left with two choices: 1. like the prototype and agree to build the "real" version starting from scratch or 2. do nothing. Either way the prototype gets thrown in the circular file.

The first example Joel gave could have been solved by a little incremental development. Instead of making a whole new prototype, branch what you have and build off it. If it took the "programmer in charge" a week to do, it might have taken the interns 4 times as long to whip up a prototype on that base of code. You like the feature, you get the pro to do it on the trunk. You chuck the intern's code anyway, but still save 3 months. And as a side bonus, the intern gets to look at a lot of professional code ... lucky kid.

So why don't more companies do this? Aren't they testing the code well enough to know when the intern breaks something (even in a prototype)? It makes you wonder. Otherwise, what you already have makes a great base for a prototype ... and you don't have to worry about your customer's ability to imagine widgets to get funding.

Agile development could also solve these prototype problems ... but don't even get me started on that one today. :)