Your engineers have just shown you a mostly working device. All they have to do now is fix those few outstanding bugs and you’re ready to go, right?
Wrong.
In his book The Mythical Man Month, Fred Brooks comments that you should always plan to design a throw-away pilot system, because that’s going to happen anyway. Building that first system is how you learn about the quirks and foibles of your particular project, and there will always be something that catches you by surprise. It’s the engineering equivalent of von Moltke’s famous quote, “No plan survives contact with the enemy”.
This is probably one of the most ignored dictums in project development, right up there with allowing more time than you think for testing (or any time at all, for that matter). Prototypes cost time and money, and there’s a strong temptation to avoid all that “waste” and get to market faster and cheaper. After all, why shouldn’t your engineers just fix up the issues that they’ve found and carry on?
Sometimes you get away with this. If the project is simple enough, the engineers are skilled enough, and the wind is south south easterly the whole time, then you can end up with a product that works out in the real world. Your headaches will only start when you try to add new features or fix the obscure bugs your customers come across.
More often than not though, there will be structural problems with the pilot system. Some unforeseen circumstance will crop up that your original design doesn’t cope well with; information may be needed earlier in the flow than you thought, the promising chips that you got samples of turn out to be made of purest unobtainium, or worst of all the project requirements may not be what everyone thought they were. Discovering these things is the whole point of writing a pilot system. You can try to soldier on through these sorts of problems, and you may even succeed in getting something usable out of it, but the pain in support issues will be never ending and will suck resources from your company forever after.
(My brother, an accountant, was once presented with new finance software commissioned by the company he then worked for. The consultants were most put out to find that some of the things they were doing with the data were illegal in his specialised world.)
The right answer is almost always to take what you have learned from the prototype and re-engineer the project. Now your hardware designers have a much better idea of the power requirements, your programmers understand more of the limitations of the chosen processor, and everyone has a much more realistic idea of what the end product will cost. Much of the pilot system will be re-used, so it’s not as big a cost as you might first think. You will probably have made compromises, but at least you will have chosen those compromises instead of having them forced on you.
Your prototypes aren’t useless, either. You can offer them to trusted customers to help weed out issues, find out what they really want, and so on. You have to manage their expectations very carefully; the prototype is not the final product and will be buggy, but handled right this is a valuable opportunity to generate excitement about your product. Just look at the reaction in the PC gaming world when something is released on “early access”; everyone knows that they are being used as unpaid beta-testers, but they are thrilled to be involved.
I’ve probably thrown away nearly as much code as has made it into products but that’s something I’m proud of, not ashamed of. Those prototypes have allowed me to try out wild and whacky ideas to see if they really work, and for it not to be a disaster if they don’t. The important thing is that I’ve learned from them, and the second attempt is cleaner, more coherent, and easier to maintain. We learn by doing. That’s the real reason Brooks is so keen on prototyping.