Prototype All The Time

I want to describe a technique I use when writing code. I call this technique "PrototypeAllTheTime". By "all the time", I mean not "constantly", but rather "very frequently".

I also need to clarify what I mean by "prototype". In the software development world the classic notion of a prototype is a small stand-alone program which is just functional enough to prove some concept. Generally the code will be thrown away after the prototype has been completed. Because of this, it's OK if the code is shoddy, bug-ridden, and incomplete -- it is, after all, just a prototype, not the real thing.

This is what we ordinarily think of as a prototype, but it's not exactly what I mean. Let's continue to think of a prototype as consisting of shoddy, bug-ridden, and incomplete code that is written in a hurry, but let's forget about this idea that it needs to be stand-alone.

Let's suppose that I'm working on version 3.0 of some program. Now let's suppose I want to design a new feature, and I'm just not sure what it should be like in any detail. I *could* write a new, simple, program from scratch -- a prototype -- to test out my ideas. But I have the source for version 2.0 of my application -- the release code that's been fully tested. I could just add my shoddy, bug-ridden, and incomplete code to the existing, well-tested code base.

This has some real benefits. If I write a stand-alone prototype for my version 3.0 feature, I may need to duplicate some functionality in the version 2.0 code base (even if it's shoddy, bug-ridden, and incomplete) just to get a prototype sufficiently operational to test my new feature. If I choose to build my prototype on the existing code-base, I get all this required functionality (and more) for free, and it's solid code, too, which only makes the prototype work better. (The only reason we might avoid solid fully functional code in a classic stand-alone prototype is it would take more time than we could justify -- but the beauty of building on existing, tested, code-base, is we get the extra functionality and robustness, and we save time, too).

OK, so now maybe you get what I mean when I say "prototyping", but for the sake of thoroughness, let me state it more formally. Prototype code is code that is shoddy, bug-ridden, and incomplete, and which is just written to prove a concept. Prototyping is what one is doing when one writes prototype code. This could be effort expended in writing a stand-alone prototype, but it doesn't have to be. Given the advantages enumerated above, most often prototyping will occur on top of a proven code-base.

So that's prototyping, and now I'm telling you that I do it all the time. Not, of course, in the sense that all the code I write is prototype code, but a lot of it is. In order to satisfy my employers I'm obligated to write "production" code -- solid, bug-free (ideally), and complete code -- the exact opposite of prototype code. But before I wrote any of that code I wrote prototype code to explore what the real code should do, or how it should do it. I don't write code every day, but pretty much every day I write code, I spend part of the day writing prototype code. Then I use the prototype code as a guide for writing proper production code.

Now let's be clear -- if I knew how to write production code right off, I'd just do that (and every now and then I do). Generally, however, I don't know how to write production code straight away, but I can always hack out some prototype code. After I've hacked out enough prototype code, I reach the point where I do know how to write production code. So then I do that, and I throw away the prototype code.

PrototypeAllTheTime serves a role in my "personal software development process" roughly analogous to ExtremeProgramming's DoTheSimplestThingThatCouldPossiblyWork and RefactorMercilessly -- especially if PrototypeAllTheTime is combined with the KeepItSimpleStupid principle. This might be yet another way to TurnAllTheKnobsToSeven.

-- CurtisBartley

CategoryTime