Last week’s post about misunderestimations (part 1) considered the practical difficulty of estimating software effort. Uncertainty of estimates is created by complexity and the infamous, but poorly understood, “unknown unknowns”. The uncertainty is too often ignored.
Consider the best way to estimate…
Team Lead: I need to know precisely how long task X will take.
Programmer: First, I will do the task. Then I’ll get back to you with an estimate of how long it took.
Since we can’t rely on hindsight we are stuck with foresight and this is susceptible to many irrational and emotional biases: pride, competition, leading questions, peer pressure, conditioning, poor communication amongst many other effects. These can wreak havoc on the accuracy of estimates even, in my experience, for rational programmers.
This post explores these biases and how they lead to misunderestimation and its rarer sibling, misoverestimation.