Techn@gerial

If you’re not willing to throw all the code away, and I mean all of it…it’s not a prototype.

I you’re not willing to press SHIFT+DEL on the entire code folder after you’ve learnt what you needed to learn… it’s not a prototype.

If you put it in Source Control… it might not be a prototype*.

If you start coding from the prototype codebase in any, way, shape or form… it’s not a prototype.

A prototype serves a specific purpose: to aid learning. Use the technique to figure out things you don’t know about your design or product idea. Use them to figure out what UX features work and don’t work. However, do not use them to form the basis of the alpha codebase or as an excuse to start coding without a design. A prototype should have a specific purpose; the object of the exercise should be to learn something, the code is simply a by-product of that learning, nothing more.

However, if your company or environment do not allow for prototyping, then don’t use them, not even a little bit. By that I mean if the purpose of a prototype is not understood or it’s considered too expensive to “throw code away”, then you’re better off not having the code available at all… you’ll only be forced to use it; the upside will be that you’ll gain the learning, the downside will be that you’ll have to fix production code as a result, which is code that you cannot simply throw away. In these situations use the Tracer Bullet technique… the subject of a future post.

O.H.

[*] Prototypes really should not have that kind of longevity, but you may benefit from branching the code to create a number of prototyped scenarios – but you’re better off avoiding source control, it simply promotes the wrong idea: that the code is important.

Tweet This Post