The Curse of Being A Developer

I am a software developer, and many people I speak with tell me how lucky I am of being able of doing everything myself. If I have an idea I can define, prototype and implement the whole thing myself.

There is a problem with that, though. I don't prototype. And chances are, if you're a developer, you don't do either.

I think people have a tendency of working always at their higher level, using their top skills when possible. As it has been said many times, simplifying is difficult, and purposefully downgrading yourself is quite unnatural. That's why I don't prototype, because I have a tendency of thinking something will be “easy”. But inevitably things start getting complicated and something I could have spotted with a simple prototype becomes a problem I am working on (and wasting my time on). I reckon there is a problem there, and my goal in this writing is to analyze the problem and start making an effort to improve my approach.

Let's analyze why this is bad

First, it delays the completion of the first milestone for your project, which should be getting feedback to validate the potential of the idea. That is, unless you know for a fact that your project will be a success, which I doubt you really do. Anything that doesn't work towards the goal of getting feedback must be avoided when possible. The only reason why you would do something now is because you think it will save you some time in the future: “Let's implement this feature so that we can reuse it later”. And I can assure you the feedback you can get from a simple prototype far exceeds any time savings you can get from code reusage. It will not only tell you if the idea is good or not, you will even change entire features which will make your “reusable code” completely useless.

Another excuse is that you simply enjoy building it. That is true to some degree, but do you really want to systematically implement everything and anything just because you enjoy it? That's what I used to do, and it brought me to this realization that I never prototype. It's a bad habit that shouldn't be the default approach. If you really do it for the sake of programming, I recommend other type of activities that are more enjoyable and have a framed time of dedication (which prevents you from over-complicating things from the start).

Finally, there is the fact that your programming skills are a valuable asset of yours. You shouldn't be throwing them away for free. When you start working on something, make sure it'll bring some value at the end. That's something The Joker and Randall Munroe know well.

So then, what is a prototype?

I hope I've convinced you (and myself) that prototyping is the way to go. So, then, what is a prototype? As I understand it, a prototype is an artifact designed to get you feedback about an idea. That's it. The feedback may be different in each scenario: it can be feedback about the correctness of the idea (will it work?), it can be reactions of potential customers to some product (will anyone buy it?), it can be an estimation of the appropriate pricing, a search for the correct public, etc.

In any case, this prototype will probably be something anyone could do, without having any programming skills. It can be some hand drawn wireframe, a market study or even a simple explanatory text (you know, an elevator pitch). And I am also sure there are thousands of applications better for creating prototypes than an IDE.

So, the next time you eagerly open your IDE ready to start your next project, think twice about it.