Tag Archives: programming

Version 0 – a tale small goals

Version 0 is a concept you are probably already familiar with, but by a different name. For me it is about getting a task or project broken down to the smallest possible building block, and laying the foundation from where to proceed.

In software that can mean something as simple and saving the file and having it print hello.

Or in finance it could be a simply as putting 1cent towards a savings goal.

Small wins which help you accomplish big goals.

Mark Twain put it best

The secret of getting ahead is getting started. The secret of getting started is
breaking your complex overwhelming tasks into small manageable tasks, and then 
starting on the first one.

Thus making the secret to finishing anything is just simply starting it. Break it down to your version 0 and just start. You can build from there and sort the direction as you go. It is much easier to change direction and go where you want, than it is to start after having done nothing for so long.

Inertia is a killer. The slower you go, the more stuck you  become, until eventually you have forgotten what it feels like to move. Or even how to move, thinking that doing nothing is actually progress.


I first began to truly understood the principle a while back. It happened after completing the work needed to upgrade the Billing System for a company I work for. The first attempt at doing it was nothing short of a complete failure. While I had set down all the goals and mapped out everything correctly, it never got to the point where it could be called working. Each attempt progressed but either I lost interest, or was pulled away onto something more important. And without a working version, no one else could pick up in the middle. Further more, given there was no base working system, every subsequent attempt at completing it was like starting from scratch and trying to finish something you couldn’t test. Guessing if each change wasn’t breaking things that didn’t work.

On the attempt that finally worked I decided that I’d sit down, then spend whatever time was needed but wouldn’t stop until it worked in some fashion. Given this constraint I started to break it down to smaller and smaller parts getting to the point of realising that the core feature is the nightly script. It reads from the database, does the calculations, then writes stuff back. Everything else is either triggered from this, or a view into the database. So I could simply ignore all of that initially.

Next was to break down the nightly script. I set out a goal of getting it to ready from the database, look for one single specific product type, check if it was due to renew, and if it was, mark it and insert a row to an invoice table.

And it worked.

An hour or two later and Version 0 was complete. It could run and handle this single case. The database tables were all there and ready to go. From there each additional feature, like making it understand all the products, or giving users a way to see their invoices from the table, could all be handled individually, as separate building blocks, all on top of Version 0.

In Sport

The exact sample process applies when training for events like The Dublin Marathon which I completed recently. You start off running a few km, then each week building on that and watch the distances get longer and longer, closer and closer to the final goal. At the start, the end goal might look daunting and impossible, so you start on this small piece that you know you can do. Then it is easy to do this next part, then this other part, and it just snowballs from there.

It is always just about starting and getting to that first measurable point. Once you see progress, no matter how small, it is easier to try for the next part. And each time it gets easier and easier.

How to apply it?

  1. Take your task and break it down to its simplest form.
  2. Break this down further so it can be measured after a few hours effort.
  3. Now try to break it down further.
  4. Start on the quickest part.
  5. Record it somewhere, be that an initial commit, a record in your training log, an entry to your accounts programme, a post-it note on the fridge.
  6. Pick the next part and repeat.


Why I(we) wear headphones while working

I’m not ignorant and I do like talking to you, honest. But getting into the flow takes time and noise interrupts in. Music in the background has always seemed to help block out the annoying thing. Its why in the early morning or late evening, so much more work is done. Sure you know yourself, you may be in work from 9-6, but you really only get about 2 hours of good work done. And now here is why.

http://softwarenation.blogspot.com/2009/01/importance-of.html provided a pretty good but basic enough explanation of the brain and how it works in sections. Combine this with what I knew previously, and it makes a lot of sense.

While programming part A, the voice in your head part,  is running away with itself, swapping variables and the like, part B, the thinking part, is looking ahead and coming up with that creative code block you are about to write. Part C, the hearing part, is being kept nice and busy by the music coming in stopping other noise coming in and ending up in the thinking part. Because when it gets to the thinking part, it is like a big freight train hitting a mountain, it derails and looses all its cargo. You start down the hill on another track, what it was you heard and the further you go, the more you’ve left behind. And just like that big freight train, it takes a long time to get back up to speed on the hill, and you have to pick up all those information bits that you lost before.