Prototyping seems to constantly confuse or scare people. When is it worth it and when is it just wasted effort. Hard question, I guess it depends…
Nuby Startup Geeks
In a past recent life, I was attempting my first startup and like any good startup geeks we came up with what we thought was a hard huge problem, fired up our editors and started coding. Then we hit a few niggles along the road, however, we always resolved to keep going and ignore reality. Why, were we just plain foolish? I guess we might have been, we were approaching the Art of The Startup as a programming assignment. We couldn’t figure that we were in a different environment. Why believe reality when we had an amazing automated test suite, refactored code to boot and cool pair programming sessions. Also, how can we bear to throw a codebase that we invested so much in – No never!! We only stopped everything and started fresh when we found competitors who were so far ahead of us that we just could not compete. BIG FAIL!!
A startup environment is a different beast, its all about trying different ideas rapidly and if they fail or don’t work just throw them away quickly and start fresh. What you want is to get a feel for the problem, as soon as you have the bare minimum start DEMOing like crazy. The code for this is basically irrelevant, if the idea makes sense we’ll throw away the code and rewrite it the correct way with all the TDD and refactoring trimmings.
Everyday Prototyping
You can take that mentality and apply it to any scenario where you want a very quick turn around on an idea. There is no real time limit here, the problem dictates how long this will take. Some problems are easy to prototype others take effort. From experience I would say that most of the time won’t be taken in the actual building of the prototype but more in researching the problem. Remember, you’re not building the real thing – so delay using that crazy sophisticated algorithm until you’ve prototyped and investigated the problem. Then you’ll have a clearer understanding of where you stand. Is the problem worth any further effort or should you stop right now. Is that algorithm still adequate or do we need a simpler or more sophisticated approach. Is … you get the picture…
Don’t Do It
On the flip side, if you understand the problem or you need to turnaround working functionality quite rapidly, as in a programming assignment perhaps for a client, building the real thing might be your only option. Also, if the time you’ll take to build the prototype is the same time required to build the real thing, just go ahead and build. However, you can still apply a prototype like approach to help you understand a problem as you’re developing it with techniques like Tracer Bullets – as introduced by the Pragmatic Programmers.
A Sample Prototype
So, what does prototype code look like? Here’s a snapshot of code for a prototype I built to understand a problem. After several demos, I decided the problem wasn’t worth it. At the time I wrote this in Rails with all the functionality in a single controller – no active-record models just plain old Ruby objects and any state was persisted in the session. It took me a couple of days. Its just a prototype, the best THROW AWAY code in the world, here it is http://pastie.textmate.org/private/8yr0ejsdnmmffzxxg4rjzg
Related stuff
Tags: geek, prototyping, startup, tracer bullets
September 17, 2008 at 10:56 am |
Hello,
Good article (found via @craigwebster’s Twitter response to you, in case you’re wondering).
In the real world, you always have to adapt to the situation, so your “Don’t Do It” paragraph makes sense, but at the same time, due to programmer optimism, most people will end up not prototyping because they feel that it won’t take much longer to build the real thing anyway (no matter how false that might be).
I guess it takes experience and some self-discipline to know how and when to write throw-away code. It would be useful to have some objective criteria/checklist to help programmers decide in a less subjective way, whether the code they’re about to write should be a prototype or the real thing.
Thanks for the article!
September 17, 2008 at 7:12 pm |
Ah yes, to code or not to code?
One of the best thing my company did was build an internal rapid prototyping tool. It’s not so relevant if you’re a lone wolf but the more guys on your team, the more likely it is to earn its keep.
September 17, 2008 at 11:32 pm |
Daniel,
A checklist is an interesting proposition, even if it serves as a basic reminder. However, it does really depend on the situation and experience is really the key.
Maybe, even start on the real thing and if things aren’t working out, you could back track and build a quick prototype. Actually, I find tracer bullets to be of super help in situations like that.
Abdel
September 17, 2008 at 11:59 pm |
hey john,
So what’s ur prototyping tool like?
At the BBC I know some departments use an open source homegrown prototyping framework called kamaelia, http://kamaelia.sourceforge.net. It contains a lot of very useful high level concurrent components written in python. Very reminiscent of, yip u guessed it, erlang’s otp.
Abdel