Code first, fail early (or why I throw away code)

I’ve been thinking a lot recently about how I go about writing new applications. I’ve worked in a lot of places and have seen first hand all styles from a waterfall style plan-everything-upfront, to a more agile approach of detailed short term plans with less detailed plans longer term. However, when I write my own applications I don’t take any of these approaches – I write code first, then throw it away. This completely goes against my gut instinct of how code should be written, it feels hacky, but it works much better than any other approach I’ve tried.

The benefits I get from jumping in to code early are:

  • I can flesh out an idea to see if there’re any issues with the approach (fail early)
  • I understand the problem domain much better after I’ve written some prototype code
  • I get an ideal if the code works from a end user point of view, much better than reading a spec will ever do
  • I can normally port some of the code from my prototype in to the final code
  • Coding is way more fun than writing specs
  • It saves me time and helps me write better applications

Let me restate that last point – by writing code and throwing it away, I’m saving myself time AND I end up writing a better application. There are many reasons why this happens – spending time in the problem domain means more time for my brain to subconsciously process what’s going on; better visibility of the issues; more likely that I’ll notice an article in my RSS reader which is in some way relevant and usable; more likely I’ll talk about any issues with friends who may have ideas about it – the list goes one. The main thing is that by getting in to the code early I give myself more opportunity to succeed.

I’m aware that writing code by yourself is way different to when you write code within an organisation; I know what I’m doing and I don’t have to prove to anyone that work is underway. This means I can spend time concentrating on core architecture, rather than rushing through it to get to concrete implementation details which in turn results in a more extendable, more maintainable, more functional codebase with less bugs.

From my experience I can understand why some companies may be cautious of adopting this process, to non techies this kind of loss leader may not make sense or seem a good use of time on a project with a deadline, but it’s in this exact situation that this approach works best. In the immortal words of The Doors “The time to hesitate is through” – write some code, throw it away; see how much you learn, and how much time you save.

Leave a Reply