Question 1

Why is software estimation so unreliable?

Accepted Answer

Because estimating software means estimating **work that has never been done before** — if it had, you would copy it — and human judgement about novel work is systematically biased in a direction that is well documented and very hard to correct.

**The underlying reasons:**

**The planning fallacy.** People predict task duration based on an imagined smooth path, consistently underestimating, **even when they know their past estimates were wrong.** Awareness of the bias does not remove it, which is the finding that makes this hard.

**Unknown unknowns.** The work that blows an estimate is usually work nobody knew existed — an undocumented dependency, a broken assumption, a system that does not behave as described.

**Estimates are made at maximum ignorance**, at the point where least is known about the problem.

**Uncertainty is asymmetric.** A task can take far longer than expected; it cannot take negative time. **The distribution has a long right tail**, so the average outcome exceeds the most likely one — and people estimate the mode while managers hear the mean.

**Non-development time is omitted** — review, meetings, deployment, support, context switching — which frequently exceeds the coding.

**Social pressure.** Estimates given in front of stakeholders drift toward what is wanted, and become commitments the moment they are spoken.

**What actually helps:**

**Relative sizing rather than absolute time**, since people compare better than they predict.

**Reference class forecasting** — how long did similar things actually take, from records rather than memory. This is the single most effective correction.

**Ranges and confidence levels**, not single numbers.

**Breaking work down**, which surfaces hidden tasks — though beware that decomposition can also inflate.

**Measuring throughput** and forecasting from observed cycle times rather than estimating each item.

**Estimating late**, once the problem is understood.

**What does not help:** demanding more precision, punishing overruns — which produces padding and hidden slack rather than accuracy — and treating an estimate as a commitment, which destroys the honesty the process depends on.

Question 2

Why does documentation always go out of date?

Accepted Answer

Because documentation and the code it describes are coupled in meaning but decoupled in enforcement — nothing breaks when they diverge, so they diverge. The core mechanism. Code has a merciless

Question 3

What is chaos engineering?

Accepted Answer

Deliberately injecting failure into a system to discover how it behaves — on the reasoning that failures will occur anyway, and it is better to discover the consequences during working hours than at

Question 4

Why is my PostgreSQL query still slow after adding an index?

Accepted Answer

An index existing and an index being used are different things. The planner chooses a strategy based on its cost estimates, and it will ignore an index whenever it believes a sequential scan will be

Question 5

What makes a good API design?

Accepted Answer

Predictability above cleverness — a good API is one where a developer can guess correctly what something is called and how it behaves, because they will guess far more often than they will read the

Question 6

Why are null references called a billion-dollar mistake?

Accepted Answer

Because Tony Hoare, who introduced the null reference into ALGOL W in 1965, later described it exactly that way — apologising publicly for a design decision that has produced an enormous quantity of

Question 7

Why is cache invalidation considered hard?

Accepted Answer

The famous quip from Phil Karlton is that there are two hard things in computer science: cache invalidation and naming things. The joke endures because the problem is genuinely difficult, and the

Related Questions