Why?

Most of my articles so far have been slightly heavy on the more technical side, this is what is looking like my forté. I find writing code and solving different problems really interesting.
OFC solving problems, especially while hacking comes with a fair degree of uncertainty and frustration...when things go wrong or simply everything turns into a big ol' rabbit hole.

I am not 100% certain whether the frustration comes from not being able to finish projects or from the perceived inability to stick to a self-imposed (albeit artificial) deadline.

So this time you will be reading some of my musings about estimations and some interesting aspects that can be found in a recent book I read that put some things into perspective for me.

How?

I have been trying for years to get close to delivering something on time. The bigger the project the more likely it is to veer off track.
The way you can get to near perfectly predictable timelines is if all the pieces in your project can be estimated with razor sharp precision and the way they will all fit together in the finished product.
Every part needs to be standard and should fit together like off the shelf components, not only that the different components need to fit together well at the end.
The book gives some statistics across projects of how often they are on time, on quality and budget, the number is dismally low across the projects that were analyzed in the book - only 0.5%.
There are some giant scale projects that have succeeded like the Empire State Building and the Guggenheim in Bilbao. The approach that seems to work well for removing the guess work is building the parts before the whole and using tried and tested solutions.

Where does it go wrong?

In software engineering mistakes are not as irrecoverable as building a physical structure wrong, of course as the impact of software systems grows the line is more and more blurred.
You can image there may come a time when the resilience of software will become as important as that of our homes...or maybe it already is and we just are unable to wrap our heads around it.
Most project examples described are delayed because of several reasons.

• the initial assumption are vague and contain hidden complexity while sounding very simple and clear
• the finished product looks slick and polished, catches the eye, but the architectural feasibility is not assessed beforehand
• optimistic estimates
• doing something that has never been done before
• the human factor
• inexperience
• unknown unknowns

My A-HA moment

I had not been able to formalize this, and had not come across a term that resonated with me until I read a case study in the "How big things get done" by Bent Flyvbjerg and Dan Gardner.
The story refers to a newspaper columnist that engages in writing a biography. His estimate was based on his experience of writing particularly long articles. This prior experience bias is called an "anchor".
In the story the writer estimates the biography of ~17 chapters at 9 months to a year, using as an anchor estimate the fact that one long article takes 3 weeks to research and write. Needless to say this estimate was off by a factor of 7. In the end it took 7 years.
The story does have a happy end in his case however this is an outlier among the various case studies.
It turns out that anchors are a very common pattern we use for estimating how long something will take.

Typically we try to find similarities within our prior experience. The catch with software projects is that technology evolves so quickly and company/team culture is so unique that it makes anchors very much a guesstimation rule of thumb rather than a rigorous framework you might use.
There are the extrinsic aspects that change and of course there are the intrinsic goals such as writing better code, designing better architectures and products, faster development whatever motivates you.
Now, given all these things that evolve over time, what would you think the probability of your experience with something in the past would equate to your estimates being accurate for a similar project two years in the future in a different company?

One thing that works is breaking the project down into decent sized components and experiment on building the components, and make the project about putting things together.
You want to work with pretty large components, yet small enough that the experiments churn out fast. It's a balancing act but in the end solving a puzzle with 1000 pieces is much harder than one with 5.
I think Agile came out of this need for faster iteration and predictability...but in the end the probability of an estimate to be accurate to the minute is very low.

Conclusions

• projects are a sum of experiments
• projects are an aggregate of the experiences of the participants
• boring technology is easier to estimate
• avoiding employee churn helps with estimating projects