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?"

10 of 483 comments (clear)

  1. My Ass by i_ate_god · · Score: 4, Insightful

    I pull numbers out of my ass.

    If I am ahead of schedule, rock on
    If I am directly on schedule, rock on
    If I am behind schedule, creatively blame something that is out of my control to begin with, rock on

    --
    I'm god, but it's a bit of a drag really...
  2. W.A.G. by ipb · · Score: 5, Insightful

    After 40+ years of programming it's still a Wild Assed Guess.

    You're never given enough time to prepare your estimate, marketing has already
    determined the delivery date, and management doesn't know what it is you're
    supposed to create anyway.,

  3. Re:It's Easy by VoxMagis · · Score: 5, Insightful

    I wish I had mod points for this - it's the most realistic answer yet!

    --
    -- I really need to bleed off some of this /. karma.
  4. Quid pro quo by HangingChad · · Score: 5, Insightful

    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.

    My time estimates will be as accurate as your specs. You stick to the specs, I'll stick to the estimate.

    --
    That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
  5. Method changes based on scope by Anonymous Coward · · Score: 3, Insightful

    Are we estimating a tweak to an existing feature? Or the creation of an architecture for a high-volume real time production system?

    That matters. Methods that are cost-effective for one are worthless for the other.

    And there are other concerns...like....how much are we allowed to spend on the estimate itself? That will put limits on the accuracy and precision (the difference between which is critical to understand in any methodology), as well as further determine what kind of estimation methodology can be used.

    In order to answer the question put forth in the summary, I will first need more relevant details.

    My experience working both with huge and tiny projects has taught me this:

    One size does not fit all.

  6. Re:Simply, no software required. by Rob+the+Bold · · Score: 3, Insightful

    I take the amount of time I think it will take, double it and move it up a time unit.

    So, if I think it will take two days, I estimate 4 weeks. If I think it will take a week, I estimate two months and so on.

    Exactly my method too. I assume we both stole it from the same place, but I can't remember where. I am also ashamed that it is often right.

    Which either means I'm lousy at estimating or brilliant. Or maybe just lousy at implementation. Or maybe nothing at all.

    But it doesn't matter, of course, since the boss will ask "Are you sure?" And we all know that that means "try to come up with an estimate that fits my predetermined schedule." So you either cut features/quality by plan or by fact. Usually by fact, since no one wants to give up anything. So you give up whatever doesn't happen to be done (or give up your release date -- which is also a feature of a sort).

    Deadlines are useful, though, in avoiding a DNF type situation.

    --
    I am not a crackpot.
  7. Re:Chop features. by 2short · · Score: 4, Insightful


    Exactly. Ship date is a feature. It will have lower priority than some features, and higher priority than some other features.
    I've never seen a team that could estimate, months in advance, when a particular feature set would ship.
    I've been part of great teams that regularly review progress and have the power to adjust priorities.

  8. Re:Uhh, Scrum is not an estimation method by JohnFluxx · · Score: 3, Insightful

    In reality, by the end of the project you are creating new backlogs as fast/faster than fulfilling them. There's always code that needs to be redone, newly found bugs to fix, performance testing that needs to be done, etc. You can't "create and agree" on performance, debugging etc backlogs ahead of time.

  9. Re:Simply, no software required. by jellomizer · · Score: 3, Insightful

    We do it backwards. The boss gives us the timeframe and we make the specs to match it.

    --
    If something is so important that you feel the need to post it on the internet... It probably isn't that important.
  10. Re:Chop features. by tempest69 · · Score: 3, Insightful

    Exactly. Ship date is a feature. It will have lower priority than some features, and higher priority than some other features. I've never seen a team that could estimate, months in advance, when a particular feature set would ship. I've been part of great teams that regularly review progress and have the power to adjust priorities.

    Shipdate was the feature dropped in Duke Nukem Forever.. So it ships with all features..