Slashdot Mirror
How Do You Accurately Estimate Programming Time?
itwbennett writes "It can take a fairly stable team of programmers as long as six months to get to a point where they're estimating programming time fairly close to actuals, says Suvro Upadhyaya, a Senior Software Engineer at Oracle. Accurately estimating programming time is a process of defining limitations, he says. The programmers' experience, domain knowledge, and speed vs. quality all come into play, and it is highly dependent upon the culture of the team/organization. Upadhyaya uses Scrum to estimate programming time. How do you do it?"
In other words: the Scotty Principle.
Show me a staff that consistently delivers products on time and one of the following will always be true:
1) One or more of your highest performers works extensive amounts of overtime (and is likely to burnout)
2) Project times are consistently overestimated.
It's a variation of the George Carlin Principle... People will adapt to fill the space, one way or the other.
http://en.wikipedia.org/wiki/Hofstadter%27s_law
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
I would recommend reading "Software Estimation: Demystifying the Black Art" [http://www.stevemcconnell.com/est.htm]. When estimates are created, there are many tasks besides "programming" that need to be done that are totally forgot about in the estimates and thus throws things off from the very beginning. We have to admit from the beginning that it is an estimate and is hinged with certain unknowns. If the unknowns are cleared up, we can be more accurate with our quoting (this is why requirements gathering should be done with careful attention). Also, since the estimates are just that, they need to not just be a number, but more of a range (if you have to give a number, choose the far end and be sure that you are confident that it can be accomplished by then - with a minimum of 90% certainty - and give the confidence with the estimate). One thing that I have learned is that I never negotiate on estimates/price, I only negotiate on functionality. If a manager/client wants it quicker/cheaper/less hours, fine, but I'm not going to change the number unless the functionality changes or more unknowns are cleared up (helping me to quote more accurately).
fortune, aptly, sprung this on me last night:
No, because the people who actually do software development know that using "parametric tools to estimate development schedules" means guessing the future based on an approximation of the past.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Hydrogen monoxide would be pretty reactive. Dihydrogen monoxide, on the other hand...
We all know what to do, but we don't know how to get re-elected once we have done it
two days, I estimate 4 weeks
Nah, by his own words, he just multiplied the actual time by 4.
8 days != 4 weeks. Guess again.
Since the units are not uniform (like metric), moving up a time unit will have uneven results across all possibilities.
2 seconds becomes 4 minutes (240 seconds) so x120
2 minutes becomes 4 hours (240 minutes) so x120
2 hours becomes 4 days (96 hours) so x48
2 days becomes 4 weeks (28 days) so x14
2 weeks becomes 4 months (Roughly 8-10 weeks) so x4-5 (as your limited set suggested)
2 months becomes 4 years (48 months) so x24
2 years becomes 4 decades (40 years) so x20
2 decades becomes 4 centuries (400 years) so x200
Average of the above multipliers: x68.75
Average of just hours, days, weeks: x33
my $quality = 100;
my $initial_project_time = length($piece_of_string) / ($count_programmers);
my $real_project_time = ($initial_project_time + ($scope_creep_time * $count_non_it_business_staff)) * $3.14;
if ($slave_driving_boss eq "yes") {
$real_project_time = $real_project_time / 2.5;
$quality = 60;
$bugs = random;
}