When the goal is to create something entirely new in a land where there is no established ‘best practice’ (which is what prototyping is after all) I’m a really big advocate of figuring out the end point and then taking many small steps in that general direction. This is counterintuitive to many people (myself included for a long time): I plan out the roads for the whole trip, rather than just saying ‘well, I know my destination is south, so I’m just going to take each South bound road I find.’


I like to illustrate this point with a little diagram.



If you have to restart the step you’re in when you run into the problem, it will cost (time, money, activation energy) you 1 to take the little-but-complete steps and 1.5 to take the long, planned route. Even if the little steps each cost 0.3, nominally summing to more than the single long step, in the end it will still be cheaper.


You need to consider what the costs of different approaches are for YOU personally. It doesn’t matter how easy it’s ‘supposed’ to be, and –especially- not how easy someone tells you it will be. That’s what makes it hard to say ‘this is a good prototyping tool and this is not.’ Someone may be able to pound out twenty CAD models in 45 minutes – if that’s the case, go for it. I find I’m better served by a pen and paper. You need to know the tools in your arsenal and are honest with yourself about those that aren’t.


The accepted best approach towards this initial stage of the process has significant variation across disciplines. The little-but-complete steps approach to prototyping is a more widely accepted practice in programming. You write a small sub-function. Test it. Write another test it. Use both of those in another function. Test it. Etc. A single, monolithic program is frowned upon (and near-impossible to debug.) The downside of this kind of training is that I’ve seen many computer scientists spend far too long in the madman phase when they’re making something that isn’t just bits and bytes.


In stark contrast, mechanical engineers seem to be trained to analyze the daylights out of everything before even looking at a screw or wire. This leads to some beautiful CAD drawings and designs that would last for twenty years. The thing to remember is that you aren’t designing something to last twenty years and the traditional methods that were designed to make the product very robust lead to planning paralysis and implementation inefficiency.


So, as you might expect, being a madman is walking a tightrope. On one side lies paralyzing over-planning. On the other, chronic under-planning awaits. But keep your focus just ahead of your feet and getting to your goal will be all the more satisfying.