To know how long something will take to do before doing it, is notoriously hard. Yet, as web developers, we’re often asked to give time estimates. In my experience, estimates become quotes which then become deadlines. Therefore, estimation is stressful. Estimation is difficult.

With a small job, it’s pretty easy to guesstimate. You know you have a development site ready to go, the project setup in your IDE and all the server credentials are plugged in ready to push your work live. A small change can be made, tested and pushed live fairly quickly. There isn’t much to go wrong, so it’s simple to estimate.

When dealing with a larger job, or an entire project, it becomes more difficult to accurately estimate. The technique I use, is to break down all the back end functionality, all the front end work and put a time against each task. This process helps break down a complex system and allows me put together a sensible time estimate.

Let me introduce you to bits in-between

Bits in-between are those unforeseen, necessary tasks which tie a system together. They’re the bits you don’t think of when breaking a system down. It’s the research, the trial and error, the page refreshing between code changes, the testing and committing work into version control (with a description decipherable by other humans). Outside of the programming itself, it’s the discussion, the unknown number of emails back and forth between you, your project manager and the client, signing a ticket off and finally, completing a timesheet entry.

The concept goes… when estimating a small job, there are not many bits in-between. The larger the project, the more bits in-between need to be accounted for.

In my mind, bits in-between are different to contingency. Contingency is a buffer added to an estimate when putting a quote together. It’s a different problem, to understand the complexity/risk involved and to quote accordingly.

Estimation isn’t an exact science but its part of the job. It’s certainly not something I was taught about. We learn by experience, and I do believe it gets easier, or, at least, less stressful. Over time, you can get a good feel for how much time those bits in-between can add to a task.

When asked how long something will take, it’s tempting to come back with the first roughty figure which pops to mind. I’d say, don’t be afraid to take a step back. In your mind, the coding itself might just take a few minutes. However, what you should come back with is an overall picture, including the bits in-between.