Over the last few years, my beliefs in how I Software should be built have changed quite dramatically. There were some years when I spent a majority of my time thinking about the solution and not enough time understanding the problem. I had some years thinking that I don’t know anything, to “I know everything” and everything else in between.

Today, I wanted to reflect on my view of Software Delivery estimates, and how my view has changed over the years. It’s one of those things that has so many moving parts to it, and you can never really have enough experience to get it quite right.

## I Know Nothing

First time I was asked to estimate how long a piece of work would take, I was terrified slightly worried that it would become an obligation for me to complete within the timeframe that I’ve given – but I was always assured that it was only an estimate.

Estimate – a guess of what the size, value, amount, cost, etc. of something might be Cambridge Dictionary

Of course, these estimates did eventually become a commitment in a form of an artificial deadline, with a multiplier for extra headroom for those unknowns that might creep in. Maybe they forgot what an estimate meant.

## Confident, But Rubbish

As I got better, I became more confident, I delivered almost everything within the timeframe that I’ve given as my estimate… eventually, Inevitably, I cornered myself into a tight deadline, so I started putting some hacks in place with // todo: haaaack - make this better.

This made me feel like I wasn’t great at what I do, or at least had a terrible judgement. I’ve become a developer that produced hacky solutions to get things out quick because of my confidence in my judgement, with full knowledge of the pitfalls of the chaos I left behind.

## Scared And Skeptical

After my confidence phase, I became scared of giving estimates, always giving answer of “it depends, what exactly will feature x do? and maybe just as important, “what will feature x not do?”, “I need to look at the state of the codebase”. Eventually, I’d be pressed for an estimate – I would give an estimate and use some multiplier depending on the risks of those pesky unknowns

At this point, experience has made me better at estimating. I also started asking the better questions to really understand the functional and non-functional requirements a lot more before giving any useful timeframe.

This approach basically meant that I’d spend a good chunk of time looking at each requirement, what the best solution is to meet that requirement is, its implications etc. and based on previous experience, give a good guess how long the piece of work would take.

I was in a much better position – I was much happier, and a lot prouder of what I produced, but me pushing back on giving an estimate didn’t make some people happy…

## Introduction Of Agile

I was eventually introduced to the world of agile, the (sort of) holy grail for productivity, continues improvement in all areas and estimation, where we don’t have to measure things by time directly, instead, we measure effort by an abstract and relative concept of points, we compute our velocity and look at how many points we have left and see how many sprints it would take us based on our average velocity, and throw in some risk factor value, then viola – you’ve just estimated a project… until you miss the deadline still because… well… you realised that, that thing that you initially thought was 5 points, is actually much much bigger, because Bob left some easter eggs in an old service that you need to integrate with.

Following the agile approach, I learned from the mistakes, I’ve become much better at managing risks.