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.
reboltutorial
August 10th, 2009
Maybe the factor should follow the Golden Ratio because it’s a spiral process like every complex process from the Universe to Life and even … Stock Market :)
http://goldennumber.net/stocks.htm
Markus
August 12th, 2009
Another reason may be that a realistic estimate would not be accepted by stakeholders, so lets get a quite nice estimate which will be accepted. :-)
dacracot
August 12th, 2009
When I was but a year or two out of college, I was asked to create a project plan for a fairly large software system. I was assigned a mentor to help with the estimating. He was fairly hands off, interjecting only occasionally… until the end. I was, after a week or two, ready to present my estimates to management. My mentor and I met a final time and he gave me some surprising advice. “Multiply all of your times by Pi.” Huh? Why? We had worked hard to get the estimates correct, and now pad them with this arbitrary constant? Why would I do that? “Because all estimates are wrong.” He said without blinking. “I use Pi because, since we are writing the code, we logically can only estimate that piece. We fail to estimate the requirements gathering. This will take as long as it takes to write the code, so we must double our estimate. We are generally over confident and don’t include the debugging time. This too will take as long as coding, so the multiplier goes to three. But, it looks too suspicious if every number is a factor of three, so I use Pi.” I did as he suggested. We were still late, but not by much, less than 10%. I still use his rule today.
Twitted by BeforeShot
August 12th, 2009
[...] This post was Twitted by BeforeShot [...]
admin
August 12th, 2009
@dacracot
this is probably an especially effective constant on projects where you feel like you’re being asked to code in circles.
moo
August 12th, 2009
I’m of the opinion that, given ANY timescale, a developer will MAKE the project take that long. That’s why we always seem to hit these made up numbers.
Gary
August 13th, 2009
Ditto Markus. I found that I was continually offering discounts to my client because, well I wanted him to succeed and, uh ok, because my estimates were low. I finally started giving him realistic estimates to cover my losses and to keep him from sticker shock, and he fired me.