Forgot your password?

typodupeerror
Programming

How Do You Accurately Estimate Programming Time? 483

Posted by Soulskill
from the step-one-invent-time-travel dept.
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?"
This discussion has been archived. No new comments can be posted.

How Do You Accurately Estimate Programming Time?

Comments Filter:
  • by WrongMonkey (1027334) on Tuesday February 09 2010, @02:17PM (#31075160)
    In other words: the Scotty Principle.
  • by TheDarkMinstrel (1671156) on Tuesday February 09 2010, @02:19PM (#31075204)
    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.
  • Hofstadter's Law (Score:1, Informative)

    by Anonymous Coward on Tuesday February 09 2010, @02:21PM (#31075258)

    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.

  • by strimpster (1074645) on Tuesday February 09 2010, @02:59PM (#31075944)
    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).
  • by adamofgreyskull (640712) on Tuesday February 09 2010, @04:34PM (#31077406)

    Exactly my method too. I assume we both stole it from the same place, but I can't remember where.

    fortune, aptly, sprung this on me last night:

    The Briggs - Chase Law of Program Development: To determine how long it will take to write and debug a program, take your best estimate, multiply that by two, add one, and convert to the next higher units.

  • Re:Chop features. (Score:3, Informative)

    by Hognoxious (631665) on Tuesday February 09 2010, @05:00PM (#31077784) Homepage Journal

    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.

  • by quanticle (843097) on Tuesday February 09 2010, @05:20PM (#31078092) Homepage

    Hydrogen monoxide would be pretty reactive. Dihydrogen monoxide, on the other hand...

  • by Anonymous Coward on Tuesday February 09 2010, @05:26PM (#31078214)

    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 Way (Score:2, Informative)

    by Island Admin (1562905) on Tuesday February 09 2010, @07:13PM (#31079696)
    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;
    }

It's NO USE ... I've gone to "CLUB MED"!!

Working...