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

• Tracer Bullets and Prototypes
• The Pragmatic Programmer
• Interview with Tim Brown, CEO of IDEO
• Deployment Monoculture

This is the usual Hello World message, a bit all over the place but we’ll get there. Before I go, I want to send a big shout to all my peeps keeping it real on twitter and elsewhere. Keep those posts coming…yeah