Conventional wisdom has it that when asked for an estimate, a programmer will recede into fitful contemplation, perhaps aided by private notes scribbled in parallel, only to produce a number that should dutifully be multiplied by three for the sake of reality. Nobody can say where this constant came from, or why it so often hits the mark. Excluding some kind of the anthropic principle, I can imagine an answer.

1st Factor: Accurate in Theory

When a developer provides an estimate, it’s usually quite accurate, derived from a history of similar tasks and projects, as applied now on the platform in question. If development transpired without challenges and unknowns, there would be no need for further multiplication, but this estimate tends to be generous on two points: (1) that any obstacles which arise can be overcome quickly, and (2) that the scope of the details can be foreseen.

A chaste estimate from a developer represents the time it would take to complete the task if they remained in an uninterrupted state of 100% productive time, all the time.

2nd Factor: R&B (Research/Refactoring and Bugs)

The second factor comes from a collective yet measured cynicism towards bugs. It’s never the bugs you expect that kill productivity, and so it’s hard to anticipate the cumulative damage they will cause a schedule.

Estimates often overlook the research necessary before implementing new technologies, techniques, or integrating with other services. Every developer will invest time in researching an optimal approach for any number of project scenarios that require such analysis, but it’s easy to overlook the process in the course of initial estimation.

Combined, research and bug hunting/refactoring out of unfeasible solutions should at worst grow to the size of the normal development schedule itself, hence the multiplier. It’s a guard limit which, should you reach, you know your project’s in trouble, but if you don’t, then you understand as a natural appendage of development.

3rd Factor: The first 90% and the last 90%

This is about overlooking details which enlarge the scope of a task from beneath. When estimating, it’s easy to mentally do class modeling or construct a theoretical workflow or protocol, but it’s difficult to envision the extent of scaffolding that will be needed to facilitate the actual task. This will take the form of helper functions, refactoring and code hygiene, design improvements, and so forth, and are the tale of elegance and quality a good developer brings to the code.

As developers we sense the presence of this work, but during the estimation process it’s much more natural to think from higher levels of abstraction without realizing what’s required to build that abstraction in the first place.

This factor also represents the strange heuristic that developers must complete 90% of a project twice before the project is really complete. When an irrational exuberance starts signaling in the back of our mind that we’re only a few methods and tests away from delivery, we can recognize this as an emotional vanguard meaning we’re, in fact, approximately halfway from having actually completed our work.