2015-03-25
Tags:programmingprocess

Getting to Code

Tweet

According to the dictionary on my Mac, one definition of prototype is

prototype

noun

a first, typical or preliminary model of something, especially a machine, from which other forms are developed or copied

I think this is a good definition, although it leaves room for subjective interpretation. Personally, I take it to mean that a prototype is something that itself is not intended for usage, but something we can derive new forms and better ideas from, which in turn may serve as the end product. Tying this together with the start-up mantra of “failing fast and failing cheap” we can conclude that it is probably a good thing if our prototype takes as little time and effort as possible to develop. This leaves more time to focus on the next iteration of the product.

Why Prototype

The purpose of a prototype is two fold

1. To test out an idea and see if it is beneficial or not, i.e., validation.

2. To deepen our understanding of the problem and its domain.

How to Prototype

So how do we prototype as quickly as possible? In my opinion it is all about getting to code as fast as possible. We must face the discomfort of hitting “New File”, opening it in our favorite editor and just start typing. We may not know the best way to do things, or have full understanding of the technologies that we are using. We must be comfortable in producing something we know will be incorrect, because it is the fastest way of learning what the correct way is!

There is a saying “failing to plan is planning to fail” and many will agree that having any kind of plan is better than having no plan. The reason for this is that once we have a plan, we can start measuring our progress and we also gain a sense of direction. This is what allows us to modify our actions and adapt our plan. The same principal applies to writing code. As we start producing code we can start measuring progress and correct our actions and goals so that we eventually end with the desired end state. But if we stay in the analysis phase, we never get this opportunity.

Fast Enough?

So is there a “fast enough” time-frame for getting to code? It may not be worthwhile starting to write code 0.3 microseconds after having an initial idea, but after a few hours of research; talking to people and checking StackOverflow, code should start being produced, otherwise you might be stuck in a state of paralysis by analysis.

It may sound extreme to expect to have code in the afternoon for an idea that popped up in the morning, but we must remember that the prototype is not intended to ever be used, it is purely a stepping stone towards the next iteration of a working product. It is this predicate is what allow us to cut corners and use the process of developing the prototype to gain a deeper understanding of the problem and its caveats.

As code start being produced it provides a tremendous amount of help in formalizing our thinking of the problem, and will also highlight corner cases and caveats that we missed when we were massaging the idea in our heads. In other cases we may feel overwhelmed by unfamiliar technologies that we recognize will need to be used for the prototype. By writing code we gain momentum and can start attacking the new technologies one by one in a very concrete and pragmatic fashion as we need them. How do you eat an elephant? Bit by bit. How do you prototype? Bit by bit. Then you throw away the code and start over. Off you go.