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.
Things had to change…
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.
Working With The Business
One of the skills that raises a Software Developer’s value is being business minded- such as understanding how to set expectations, the business motivations for the project, giving visibility of progress and how to communicate them to the wider business etc.
Reality of being a Developer is that being one of the best at delivering great technical solutions to a business problem isn’t enough, we have to be able to work and communicate with the business that we are serving to maximise our impact.
This ultimately means, deadlines will always exist, and we just need to get better at it.
Defeat Acceptance
I’ve come to accept that there’s no accurate way of predicting when a Software Project will complete. No two projects are exactly the same, regardless of experience you have of working with a particular domain, technologies, team etc. there will always be some other things that will make a project unique from everything else you’ve ever done.
Next time you’re asked to give an estimate for something, think of the risks, what can go wrong? is it a critical path and completely halt progress if this risk did come to fruition? Is the team really familiar with the tech I need to use to solve this problem? Do you even really understand the problem to begin with?
