Forgot your password?
typodupeerror
Programming Software

Overconfidence: Why You Suck At Making Development Time Estimates 297

Posted by Soulskill
from the i-blame-the-schools dept.
Dan Milstein from Hut 8 Labs has written a lengthy post about why software developers often struggle to estimate the time required to implement their projects. Drawing on lessons from a book called Thinking Fast and Slow by Dan Kahneman, he explains how overconfidence frequently leads to underestimations of a project's complexity. Unfortunately, the nature of overconfidence makes it tough to compensate. Quoting: "Specifically, in many, many situations, the following three things hold true: 1- 'Expert' predictions about some future event are so completely unreliable as to be basically meaningless 2- Nonetheless, the experts in question are extremely confident about the accuracy of their predictions. 3- And, best of all: absolutely nothing seems to be able to diminish the confidence that experts feel. The last one is truly remarkable: even if experts try to honestly face evidence of their own past failures, even if they deeply understand this flaw in human cognition they will still feel a deep sense of confidence in the accuracy of their predictions. As Kahneman explains it, after telling an amazing story about his own failing on this front: 'The confidence you will experience in your future judgments will not be diminished by what you just read, even if you believe every word.'"
This discussion has been archived. No new comments can be posted.

Overconfidence: Why You Suck At Making Development Time Estimates

Comments Filter:
  • by Anonymous Coward on Tuesday April 23, 2013 @04:59PM (#43529631)

    'nuff said.

    We've all been under pressure to give our "best" estimates and then some.

    Give a realistic estimate? Off to India!

    • Experiment (Score:5, Interesting)

      by trout007 (975317) on Tuesday April 23, 2013 @07:47PM (#43531285)

      I would love to see an experiment. Take two groups and give them the same job. Group one would be based on a typical American corporate structure with a Boss, Scheduler, budget person, middle management, supervisor, and finally people doing the work.

      The other group would have the same number of people but only those that work. No schedule or budget just work until it's done. I wonder what the results would be?

    • Exactly. If someone asks me for an impossible prediction, I will give them what they asked for with unyielding confidence. When faced with the inaccuracy of my prediction, I will continue, with confidence, in giving equally inaccurate predictions in the future.

      My real algorithm is as follows:
      Is it fun/interesting to do? If yes, feel the room and give an estimate that will keep the project from being killed. Else, give a long enough estimate that can withstand cross examination that hopefully will kill the p

    • by hackula (2596247) on Tuesday April 23, 2013 @11:30PM (#43533053)
      management/sales: how fast can we get this done?

      dev: low 3 weeks, mid 5 weeks, high 9 weeks

      management/sales:Great! I was hoping you would say around 2 weeks, because this product is being launched next week, so if we push it, we should be able to get it out the door by tomorrow approval!
  • by mark-t (151149) <`markt' `at' `lynx.bc.ca'> on Tuesday April 23, 2013 @05:00PM (#43529655) Journal
    Points 2 and 3 don't seem to apply to me. I know I suck at doing development estimates. When asked for one, I've never been particularly confident about any estimate I give having a good chance of being accurate. I want to estimate conservatively, but project schedules don't allow for that.
    • I guess part of being an 'expert' is being dumb enough to buy your own crap. That's why they always seem so sure of everything. Meanwhile, folks like you and me hedge our bets, and people attribute that to not knowing enough, rather than knowing all too well what the real deal is.

      I suspect that prior to being an 'expert', that person makes one wild guess that they nail bang on. After that, they just point back to the ONE TIME they were right, and that carries them for the next few years.

      • I guess part of being an 'expert' is being dumb enough to buy your own crap. That's why they always seem so sure of everything. Meanwhile, folks like you and me hedge our bets, and people attribute that to not knowing enough, rather than knowing all too well what the real deal is.

        I suspect that prior to being an 'expert', that person makes one wild guess that they nail bang on. After that, they just point back to the ONE TIME they were right, and that carries them for the next few years.

        The other problem is that when you're regarded as being an expert and and 2 & 3 don't apply, giving an estimate that hedges for realities to happen doesn't satisfy management. You get accused of padding hours, being difficult, or playing favorites (if there are multiple approaches being evaluated). What's weird is that after this song and dance, they still expect you might run a week late...

    • by nine-times (778537) <nine.times@gmail.com> on Tuesday April 23, 2013 @05:57PM (#43530279) Homepage

      I wish people would understand that project schedules should *only* be considered guesses and estimates. Take the time you think it will take, and then take a step back and ask yourself, "No really, how long will it take?" When you get a number, take another step back and ask yourself, "No, *really*, when a bunch of things go wrong and it takes longer than I expect, how long will it take?" And then treat that time frame as a best-case scenario.

      Part of the problem is that many projects can not be set to a specific schedule. The real answer is usually "it depends". How long will it take to build a new website? Well it depends on what unexpected hurdles we run into. It depends on how many features you want to add after we begin. It depends on how many revisions we go through.

      When people ask me to set a firm deadline, I'm always tempted to ask them, vaguely, "When we don't meet that deadline, what do you want me to sacrifice?" Any deadline can be met if you sacrifice enough of the project requirements. So if we're coming up on a deadline, would you rather I miss the deadline or that I sacrifice some of the requirements? That is, let's say you want a website running with features X, Y, and Z, and we have a deadline of June 1st. The question isn't whether I can meet the deadline of June 1st. The question is, on May 31st, when feature Z isn't ready (there will be some feature set "Z" that isn't ready), do you want to go ahead and launch the site anyway? Or is Z worth holding up the launch?

      In other words: project managers should should focus on priorities rather than schedule. "Being on schedule" and "being within budget" are just two more features that need to be prioritized within the set of features that a project is trying to meet.

      • by mark-t (151149)
        It doesn't matter whether or not a project "can" be set to a specific schedule... a client will still expect a deliverable on date X.... and if there isn't, well... the client will simply stop paying you (sometimes there are even penalties imposed for lateness), and you have to finish it for free. Given the choice between doing jobs for those kinds of clients or not having a job at all... I'll take the option that keeps my mortgage payments up.
        • by bondsbw (888959)

          This is a bit presumptive. Sometimes the deadline matters most to the client, and sometimes completeness/correctness matters most. When you perform an estimate (which should always be a range), and the client has specified a deadline (a specific date), ask them this question:

          "When the deadline comes, would you rather the project be incomplete but ready for delivery, or would you rather push back delivery in favor of complete and correct software?"

          Communication with the customer is essential, and continual

      • by Kjella (173770)

        Take the time you think it will take, and then take a step back and ask yourself, "No really, how long will it take?" When you get a number, take another step back and ask yourself, "No, *really*, when a bunch of things go wrong and it takes longer than I expect, how long will it take?" And then treat that time frame as a best-case scenario.

        The thing is it's not *that*. First I take how long it should have taken and multiply it up to how long it's going to take. Then I factor in all the other things related to the project that I'm likely to get sucked into while working on it. Then I factor in all the other factors like staff meetings, client down, server down, network down, fire drill and whatnot. Try getting some experience data on how much time you get to spend doing what you're supposed to be doing, you might be surprised. Also if somebody

    • by Sponge Bath (413667) on Tuesday April 23, 2013 @06:16PM (#43530473)

      I know I suck at doing development estimates.

      A struggle is getting people to even agree on what a development estimate is:

      Me: "That will take 2 months of development work."
      [two months of interruptions, putting out fires and "prioritization" later]
      Other: "Why is this not done? You suck at development estimates."

      • by el cisne (135112)
        This. Had a boss one time ask me for an estimate. I was intimately familiar with the C++ code and said 3 months. He didn't believe it, so he asked someone else who told him 6 months. Yet another told him a year. Who did he go with? His buddy that told him two weeks. FML
      • by mark-t (151149) <`markt' `at' `lynx.bc.ca'> on Tuesday April 23, 2013 @06:40PM (#43530697) Journal

        The first thing you did wrong is that you estimated 2 months, without taking any time to break down how you were going to spend each and every day of that two months. If you had done that, you would have realized you were falling behind schedule within the first week.

        In my experience, any estimate that's longer than 1 day, and often even as little as half a day, generally should require breaking down, so that it is clear exactly what needs to be complete. You break the programming tasks down almost to an atomic level, so that every discrete function of the software is described, along with how long it will take to implement each one. Sometimes you don't know how long something will really take, but that's okay... the time it takes to estimate a project should be factored into the time it will take to complete it. Breaking things down at this level also gives you a clearer idea of the technical requirements to complete the job in the first place, which helps you design technical solutions as you make headway in the project. Further, it gives you a metric once you are partway through a project to determine based on how much of the project you've actually completed within a given time, whether you are even going to complete the project within budget, and if not, institute measures to minimize losses. In practice, you're not going to be right every time, or even necessarily close to being right, but when broken down to this level, the overestimates and underestimates should balance out reasonably well, with perhaps a tolerance of up to about 10 or 20%. If they don't, then there's something else fundamentally wrong with the project, and as a first guess, I'd suggest that it may be on account of unclear program requirements,

        • Sometimes you don't know how long something will really take, but that's okay...

          I agree with everything you said, but the point I was trying to make (poorly worded), is that time spent doing something other than development does not advance development. I always pad for the unexpected, but if you pull me off a project to do something else, then that project is not progressing. It sounds like a basic concept, but it escapes those who are not responsible for the actual development.

      • by dkleinsc (563838) on Tuesday April 23, 2013 @08:38PM (#43531741) Homepage

        That's why I always say "That will take approximately 270 hours of development work" rather than "That will take 2 months". Then you write down how your time is actually spent, and can document that after 2 months you've actually only had 20 hours to devote to whatever it was, so it's no surprise that you're a long way from finished.

      • by Blue23 (197186) on Wednesday April 24, 2013 @12:16AM (#43533335) Homepage

        I know I suck at doing development estimates.

        A struggle is getting people to even agree on what a development estimate is:

        Me: "That will take 2 months of development work."

        [two months of interruptions, putting out fires and "prioritization" later]

        Other: "Why is this not done? You suck at development estimates."

        Then make sure you're not surprising them at the end of 2 months. If at the end of week 1 you go to them with "I go two days against the project this calendar week, we still have 38 more to go", they are in the groove for project time and calendar time isn't the same. And if they want them to be, they need to stop you from getting interrupted.

        Communication. Verrrrrrry important.

    • I've never been particularly confident about any estimate I give having a good chance of being accurate

      I tell IT folk and non-IT folk the same thing: an IT estimate is the first point in time having a non-zero probability of being true.

      They both appreciate the truth of the adage. Like somebody else said, multiply by pi. That takes into account the 'problem surface' around the vector.

  • Predictions on the time it takes for me to do something can be off, but not by much. Most good predictions have contingency plans, etc...

    In my experience, the biggest variability in estimates is the reliance on external dependencies. If I were the only person needed to work on something and I estimated 40 hrs of work, I would probably get it done in 30-45 hrs. But when that works requires someone else to do something at a critical point, even if it only takes 1 hr, the ability to acquire that resource in

  • Well, I at least have my wife trained to treat my time estimates as "no sooner than", and I don't have any trouble sticking to those commitments. Can't be that much harder to train your boss to have the same expectations.

    Anyway, isn't most of Agile centered around coming up with time estimates formed from a consensus of team members who know you well?

  • by Capt.DrumkenBum (1173011) on Tuesday April 23, 2013 @05:02PM (#43529683)
    Always tripple all estimates. That way you always look like a miracle worker.
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      I have a PM who actually does this. He takes everyones estimate by 'pi'. He says it works and has theories why it works. But just knows it does. In my exp he is right. Someone says 'it will take me 2 hours', it will take them about 6-8 hours.

      Only with the dead easy tasks are people spot on. Anything else they are usually wildly guessing. Unless they have done it before (and even then...).

      • by slew (2918) on Tuesday April 23, 2013 @05:36PM (#43530039)

        He takes everyones estimate by 'pi'....In my exp he is right.

        If your PM takes somebody's imaginary estimate and multiplies it by pi and you exp it, your result will necessarily be complex, yet the error will be easy to bound with a circular range (even if with an initial wild guess)... Just say'n...

        • He takes everyones estimate by 'pi'....In my exp he is right.

          If your PM takes somebody's imaginary estimate and multiplies it by pi and you exp it, your result will necessarily be complex, yet the error will be easy to bound with a circular range (even if with an initial wild guess)... Just say'n...

          How dare you frame a humorous anecdote in statistics, and render it completely logical and un-funny.

    • by mark-t (151149)
      No, actually, you look like a crappy estimator. In game development especially, projects don't typically have enough of a development budget to afford to overestimate by a factor of 3, so when you tell somebody it's going to take 3 days to do a task you think you can actually finish in one, the producer's only going to ask for a detailed breakdown and justification about why it's going to take so long... and when you end up describing how it will take several hours to implement something you should be able
      • Actually, doubling or tripling the estimate is USUALLY correct, the problem is that it's not correct if you apply it all at once. I've known managers that take any estimate and double it, but crucially, you don't allocate the effort all in one block.

        If you need to code a widget, and it'll take you 3 days, realistically, that's just for the initial implementation. You can debug it, but that's no guarantee that it'll work as intended all the way until the end of the project. You probably have another 3 days o

    • by steelfood (895457)

      So you're saying that the real date of the events in Star Trek was actually the year 6795?

    • In not sure why anyone thinks this funny, because it's absolutely true.

      No matter how much experience you have, there will *always* be that huge feature you initially thought would be a minor thing, there will *always* be those impossible-to-predict functionality hangups that take forever to solve and the client will *always* have "oh, yeah, and..." types of changes to the project requirements that completely alter the scope.

  • If you think it will take an hour, say it will that three, then when it takes two you're a genius for getting it done so fast.
    • by Takatata (2864109) on Tuesday April 23, 2013 @05:09PM (#43529753)
      Than a competitor will say it will take two hours and get the job. Ok, finally it will take four hours, but still, he got the job.
      • by ADRA (37398)

        And when it invariably takes them 4 hours to implement the feature and their sales 'win' ends up costing them more than the value of the contract, natural selection works its way though and they can instead estimate how long it'll take to find a new job.

    • But what if you think it will take an hour, say three, and then take four hours? Most people are already padding their estimates and the estimates are still low.
  • by invid (163714) on Tuesday April 23, 2013 @05:05PM (#43529717) Homepage
    It took me a few years for me to discipline myself to including testing and bug fixes in any estimate I made to managers. When ever I would say, "I'll finish coding by X," they would always assume that it would be in release condition by then.
  • by Anonymous Coward on Tuesday April 23, 2013 @05:05PM (#43529723)

    I often find another problem is management's refusal to accept the estimate of the developer. I am usually pretty good at estimation. Here is what usually transpires for me:

    Manager: "How long will it take you?"
    Developer: "2 months."
    Manager: "You don't have 2 months. You only have 1 month. Redo your estimate. How long now?"
    Developer: "2 months."
    Manager: "You don't have 2 months. You only have 1 month. Redo your estimate. How long now?"

    At this point I feel like saying:
    Developer: "Why are you asking for my input? Just write down 1 month. And do you want me to tell you I will be 1 month late right now or in 1 month from now?"

    • by invid (163714) on Tuesday April 23, 2013 @05:13PM (#43529779) Homepage

      I was once invited to a meeting with the customer because my manager was sick. When people started talking schedule I casually mentioned the 18 months it would take to complete the software. The customer went ballistic. Apparently the schedule I gave my manager never made it to the customer.

      I was never invited to a meeting with the customer again.

    • by Platinumrat (1166135) on Tuesday April 23, 2013 @05:26PM (#43529937) Journal
      I'm constantly getting this effect at work now. My current manager (who has no technology background or experience) is always challenging my 25+ years experience. I've already felt the pain of optimistic estimates and now include everything, requirements, documentation, design, code, integration, test, more documentation, installation, commissioning and support in an estimate.

      He comes out with the following gems:

      - "I believe your estimates are too high"

      - "I've already committed to a delivery schedule with the CEO and Engineering Manager"

      - "Well, we'll just have to challenge your assumption"

      - "We'll just have to find ways to work smarter"

      - "We'll just need to work extra hours then"

      - "You're not showing enough committment", when asked to work on the weekend and holidays. This despite being with the same company for my entire working life

      It's like I'm in a Dilbert nightmare now.

  • That it'll take 2x-3x longer than it takes in my head. If there are no spec changes (i can dream, right?) or other surprises, maybe put that down to 1.5x.

    When given a project, I'm sure most people will have a macro-level architecture thought up within minutes. It all seems so easy at that point! If you're lucky you get to spend a little more time in thought before being asked for a time estimate. If you're unlucky, well... in those cases I just multiply by 3. Underpromise, overdeliver and all that.

  • My team seems to do ok on the estimates. Then we get beaten into 1/2 that by management. Then in the end it takes twice as long as management expected. So the original estimate was good.

    So we would be fine if only management did not try and squeeze it.

    Management never accepts the "debug", "refactor" and "new feature" timelines, those are generally considered as "not needed". It just supposed to work perfectly and on the timeline they negotiated before consulting the people who would actually deliver it.
    *sig

    • I agree. Fortunately for me at least, I happen to be in the happy world where management supports us in realistic timelines and realistic scoping.

      Spanning almost seven years now and well over a hundred assorted projects we have been overdue on projects two times total. One of those was during the exceptional case of a co-worker getting in a car accident and breaking 13 ribs, the other was an exceptional case where very serious external forces caused the design to shift mid-development. In no case has it

  • by Anonymous Coward

    Blah, blah, blah. Bad estimates.

    Blah, blah, blah. Oh noes! Waterfall!

    Blah, blah, blah. Fixed by Agile!

    • by uncqual (836337)

      Pretty good summary.

      The solution seems to be "don't commit to a schedule longer than a sprint (even if that's only a week) and you won't be far off on the average".

      Of course, this doesn't work so well with customers. A giant customer who is considering kicking your product out the door and replacing it with a competitor "if you don't get feature X in" wants to know when he can expect feature X. This is often easy for seemingly small projects (add a new style sheet), but not so much for "hard" (many tens of

  • But it's not really that hard to predict estimates where predictable and predict a reasonable time to determine if an area is predictable.

    The RUP methodology is excellent for this.

    1) You gather the feature set and identify the risk vs non risk portions of a project.
    a) New technology.
    b) Relying on develop of technology which doesn't even exist yet.
    c) Performance.
    2) You work on the risky items first. You do not start on the non-risk portions until the risks are mitigated.
    3) Work in a time-boxed fashion. The

  • It's easy to manage time if you keep this simple law in mind:
    The first 90% of the work will take up the first 90% of time, and the remaining 10% will take up the other 90% of time.

  • Scotty knows (Score:5, Informative)

    by u64 (1450711) on Tuesday April 23, 2013 @05:18PM (#43529853) Homepage

    La Forge: The Captain wants this spectrographic analysis done by 1300 hours.
    Scotty: Starfleet captains are like children. They want everything right now and they want it their way.
    But the secret is to give them only what they need, not what they want.
    La Forge: Yeah, well, I told the Captain I'd have this analysis done in an hour.
    Scotty: How long will it really take?
    La Forge: An hour!
    Scotty: Oh, you didn't tell him how long it would *really* take, did ya?
    La Forge: Well, of course I did.
    Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.

    - TNG 6x04

  • Use a OUIJA board, or, do some decent project management planning and know thy tasks, thy players and thy resources at your disposal.
    For the most part, double your estimates and then adjust where it gets too costly and you know your players can perform fast than expected.
  • Lt. Commander Geordi La Forge: Look, Mr. Scott, I'd love to explain everything to you, but the Captain wants this spectrographic analysis done by 1300 hours.
    [La Forge goes back to work; Scotty follows slowly]
    Scotty: Do you mind a little advice? Starfleet captains are like children. They want everything right now and they want it their way. But the secret is to give them only what they need, not what they want.
    Lt. Commander Geordi La Forge: Yeah, well, I told the Captain I'd have this analysis done in an hour.
    Scotty: How long will it really take?
    Lt. Commander Geordi La Forge: An hour!
    Scotty: Oh, you didn't tell him how long it would *really* take, did ya?
    Lt. Commander Geordi La Forge: Well, of course I did.
    Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.

    It also helps you plan time for unforeseen setbacks.

  • So true (Score:5, Insightful)

    by Dixie_Flatline (5077) <vincent.jan.gohNO@SPAMgmail.com> on Tuesday April 23, 2013 @05:20PM (#43529887) Homepage

    I hate making estimates. I'm always, ALWAYS wrong. I always know I'm GOING to be wrong.

    I've been trying to fix this for 12 years. I thought it was just inexperience talking, but I'm a grown-up programmer now. 'Senior', by some estimates. And yet I still have a hard time estimating the time of getting things up and running. I write one thing, and four things that I couldn't have anticipated crop up. This is particularly true in my industry (video games) where you're often working with an engine that's a few years old, and other people are in the middle of working on it, and specs are changing under everyone all the time. Things that look straightforward end up taking bad detours through networking components that nobody else understands because that part was written years ago and those programmers aren't around anymore.

    Man, this story makes me feel a lot better about myself.

    • by fl!ptop (902193)

      I thought it was just inexperience talking, but I'm a grown-up programmer now. 'Senior', by some estimates. And yet I still have a hard time estimating the time of getting things up and running

      You need a "rule of thumb." I had the same problem until I decided that the minimum a project would take for basic functionality is 4 hours for each table in the database. If they need fancy ajax stuff or any eye-candy, then it goes up from there.

      It's worked pretty well for the past few projects. I've even come in

    • I know, insert prelim apology for sounding "arrogant" etc. Then let's thrash out a theory.

      "I've been trying to fix this for 12 years." When something takes 12 years to get better at, there's hidden factors at play.

      Suppose you try a thought experiment. Imagine one of your recent projects. So you get to the stage of the "estimate" (really some kind of pre-pre-pre estimate!) and imagine what you were thinking when you worked it out.

      Then try to pin down at least a couple of the "oh my gawd" moments when the who

  • I started to get offended at this broad generalization that experts can't make accurate estimates. And then I realized that no where in the summary does it say anything as to the absolute value of anything. It uses phrases like "extremely accurate" or "extremely confident". If someone takes a 1,000 hour project, and predicts it will take 1002 hours +/- 1 hour, is that a failure? Or does the OP mean the expert says 1,000 hour project is predicted to take 10 hours +/-1 hour is a failure. What is this con
    • I think the article is saying most people are not experts but rather confident proffesionals. They know how to do their job. They can program the thing your asking them to do. But this doesn't make them expert estimators. To estimate properly you need to be collecting data on yourself. You need to be basing your predictions on that recorded record. You need to be looking at the acuracy of your previous predictions and providing a margin of error based on data. To be a true expert that margin of error needs
  • Hofstadter's Law (Score:5, Insightful)

    by cant_get_a_good_nick (172131) on Tuesday April 23, 2013 @05:25PM (#43529925)

    Hofstadter's Law [wikipedia.org]:

    It always takes longer than you expect, even when you take into account Hofstadter's Law.

  • In my previous life as a software architect for a small rural software development shop, I would try to give estimates and my bosses (all salesmen) would come back with, "I can't sell the client that!" Then when I missed the deadline or had to work weekends they were quick to blame me for giving an unrealistic deadline. My favorite line was always, "Give me an estimate, I won't hold you to it." Yeah. freakin. right.

    Even better is when I would attempt to show them what other SUCCESSFUL development shops w

  • by ADRA (37398) on Tuesday April 23, 2013 @05:29PM (#43529969)

    People estimate based on how much time they think it -should- take, but you almost never estimate:
    1. External factors which grow time
    2. Feature/function clarification takes time
    3. Outside resource turnaround takes time
    4. QA may never be satisfied
    5. We're moral and WE make a lot of mistakes along the way
    6. Most likely, you don't know all the caveats of developing the piece of work until AFTER the development is over
    7. General personal time spent elsewhere (meetings, consulting with co-workers)

    Sadly, the best estimate for completion ends up being 1.5-2x longer than my original gut check, so as long as you pad out your estimates, you should be fine.

  • The so called 'experts' are just as much experts at estimating requirements and timing as they are 'expert architects'.

    Here is a thread [slashdot.org] where I argue that J2EE is a crutch given to people labelled as 'architects', turning them into typists while removing any real architectural thought from their activities. If you read through the thread you'll see some AC objecting to that notion and he does not realise that he is arguing my points there when he talks about architects.

    He is mistaking what 'enterprise' mean

  • Level of Detail (Score:4, Interesting)

    by cant_get_a_good_nick (172131) on Tuesday April 23, 2013 @05:31PM (#43529985)

    Back when Joel spent time on writing, Joel Spolsky of Joel on software had an interesting method for doing time estimates [joelonsoftware.com]. His point was to go into a deep level of detail. Instead of handwavy "code the GUI" the only way to really get anything remotely close to a real time is to estimate everything down to at least half day, if not lower granularity. It's not the "oh you feel the time better" as much as to think of EVERYthing you need. If you go to a lower level, you may remember that dialog box that you didn't think of at the 25,000 foot level.

    It would be interesting to see if anyone ever used it to improve their estimates. Even he "disavows" it now, preferring the method in his software tool. But I like the "the world is a big place, are you sure you're thinking of everything" that the older method pushed you to.

    • I estimate that my estimate will take 40 hours for small projects and 3 months for long projects. It will only take me 40 hours after my estimate is done on the three month estimate to finish the program. It will take me 8 hours to finish the project after my 40 hour estimate. Multiply what I give you by 3.
  • by pkinetics (549289) on Tuesday April 23, 2013 @05:36PM (#43530037)

    Something my boss has us do when we estimating projects. She has a certainty factor that we set for each task, simple terms, which equate to a percentage in her calculations. The higher our certainty, the less risk that the task is underestimated. The lower the certainty, the larger the margin that the estimate needs to be factored.

    Makes a huge difference in ballparking our estimates.

  • As per my blog post a couple of years ago at http://use-cases.org/2011/06/04/getting-good-estimates/ [use-cases.org] [use-cases.org] and http://use-cases.org/2011/06/22/updates-on-getting-good-estimates/ [use-cases.org] [use-cases.org]

    Most good estimates have a range - and not a number, or a number with a confidence (both are interchangeable).

    If an engineer says it will take two weeks - I push for a range or a confidence. If the range is weird (2-8 weeks), I push for the engineer to tighten their estimate through discussing or raising and discovering the unknowns or the risks that they are aware off. That sort of estimate would usually end up around 3-5 weeks which is a reasonable margin - and a lot better than than underestimating by 50%.

    Same with estimates that are too narrow. "2 weeks +/- day". That implies a full level of understanding, no risk and no dependencies. Almost never happens. Work through the same risks/unknowns and the estimates usually become really bad - typically at least double of the "high confidence" estimate - similar to TFA.

    There is a lot of reasonably applicable theory behind this (confidence intervals, cone of uncertainty, etc). But we don't necessary focus on mastery of our art...

  • 3 days for bitching, pissing and moaning.
    3 days for dicking around on the interwebz
    1 day lunch overages.
    2 days for "zoning out"
    3 days for witty banter.

  • People setting around the meeting table.

    Suit: "How long do you estimate development will take on this project?"

    You: "My best estimate is 2 years, 3 months, as long as specs don't change."

    Suit: "But the customer would like the product in a year"

    Bean counter: We'll need 6 months to determine the task flow".

    You: Then you'll need to add six months to the scehdule."

    Suit: Okay, it's settled. We'll start tommorrow, the accountants will take the first six months to determine the charge numbers, and the

  • During my last project, one component was estimated (by others) at 2 man months, and it ended up taking 6 full time developers a year to implement. The estimates were absolutely horrible. As much as it was the fault of the original estimate, management constantly rode the development team to get it done asap, which probably in the end did more harm than good.

  • by linuxguy (98493) on Tuesday April 23, 2013 @05:44PM (#43530161) Homepage

    When my customer comes to me and asks me to provide an estimate for a job, if I give them a conservative estimate, some of them may think that I am milking them with the extra hours. Specially if they get a competing estimate from an overly aggressive Indian company who is eager to sign the contract but has no clue on how to deliver.

    I usually do not fret too much about customer feelings in a case like this. But during slow times I have little choice. Bottom line is, most of us would love to provide conservative estimates, but often times it is not as simple as that.

  • ... to be developed for them in 3 months. I estimated 10 months. So they decided to look around for another developer. A couple years later they came back and asked if I could do it in 6 months. I told them it would take 12 months, now.

  • You can have confidence in your estimates and still be aware that that confidence is misplaced. One of the common things I keep saying to my manager is "Yes, I'm pretty sure we can finish this in 3 weeks. But I want to schedule it for 6 because always, always we spend half our time getting pulled off onto other things and I want to account for that now before we get in a bind.". I have confidence in my estimates, but I also have confidence in the statistical evidence of how reality varies from my estimates

  • Uh no... (Score:5, Insightful)

    by Charliemopps (1157495) on Tuesday April 23, 2013 @05:59PM (#43530303)

    My estimates suck because:

    Project leader: Ok, so we need to know how long it will take for you to do X
    Me: I'm not sure, that's an entirely new API, proprietary to the vendor, there's almost no documentation and their website has a support forum filled with questions and basically no replys to any of them.
    Project leader: Well, we need a number.
    Me: Why?
    Project leader: I have to fill in this box here... see?
    Me: Ok fine, 800 hrs
    Project leader: Now hold on a minute, this wont take 800hrs
    Me: It could, I have no idea. It's already taken the majority of at least one hour and I don't even know what language it's in.
    Project leader: Fine, I'll put down 800hrs, but you're the one that's going to look silly.

    POST PROJECT REVIEW
    Project leader: I can see here your original estimate was 800hrs, and your actual billed time was 1265hrs. What causes led to you missing your estimate, and how can we avoid those in the future.
    Me: Don't make estimates.
    Project leader: Come on now, I need a real answer.
    Me: Why?
    Project leader: I have to fill in this box here... see?
    Me: ....

  • Anyone who calls themselves an expert isn't qualified to call themselves an expert.

  • We did that in the college research game. A prototype was already done before we applied for a grant. We used the money to perfect the old project and start a new secret project. Nothing succeeds like existing success.
  • Think about it.

    Time is, for all practical purposes, linear. Your task will take a specific quantity of time to complete. You don't know that quantity of time in advance, because you don't control all factors, so you're guessing.

    Now, what is the environment of your guess? You are trying to pick out a specific point in the future at which your task will be done.

    Balance that against the infinite number of points of time in the unbounded future in which your task could actually be completed in.

    1 estimated point

    • nah to win your estimate only needs to be within 10% of your estimate. If you estimate 40 hours management is going to be happy between 36 and 44. between 20 and 80 hours no one wins. At 360 hours you lose.
  • Here's how you do it: You split your development task up into small parts that should take 1 to 5 days. For each task, you write down your best estimate. Now of course you know you are bad at making good estimates, but that doesn't matter: You do the first part, then write down what you estimated, and when you actually finished. From that you extrapolate when you will finish - if you estimated two days and it took three, you estimate that the whole task will take 50% longer than estimated. After the second
  • Break the problem down into parts. Carefully consider contingencies. Get creative - sleep on it. Think about it in the shower. What bullshit will crop up as I work on this project?

    Using all your experience as to how long similar components took to implement in the past, plus how much longer it would have taken if worst case nuclear godzilla attack had occurred, compute time estimates for each component.

    Add all the time estimates together.

    Multiply by the Planck constant in Joule seconds / (pi^3 / e^2) *

  • "The hardest part of solving a problem is understanding it" - ?

    The reason its hard to estimate development time is because programming involves design, design is a creative task.

    Nobody can predict how long it takes to be creative, its a universal unknown. Creative workers (such as graphic artists) often estimate the design phase by giving themselves a hard limit and then just choosing the best idea they could come up with.

    Most programmers dont even acknowledge their work is a creative expression, so they ar

  • Because by the time anyone who could come up with accurate estimate is asked for their opinion, the product has already been sold and the contracts signed.

    Prioritise the order of development and get on with it. It'll be done when it's done, you'll get paid or you won't. Wasting time producing imaginary numbers has never fulfilled a contract, ever.

  • Start by prototyping before the project is funded. This helps the business parties see what is possible and also gives the developers a much better understanding of functional requirements than any document ever could. Do UX testing sessions (test using your best developers - they find cool hacks, and business people, and anyone). Evolve the prototype, if even over a couple of weeks (I'm pretty good at rapid prototyping, two weeks is usually enough for 2-3 revisions resulting in a reasonably functional p

  • I too partially suck at estimates. Aside from the "unknown unknowns" which you can budget for but never predict I have found several rules of thumb have got my estimates from "fairyland guesses" to "accurate with withing a factor of 2". These are:

    • * If you have done the exact same task before using the exact same technology then your estimate is probably good to within around 20%
    • * If you are using new technology, a new technique then you have no real estimate. Have to be super conservative with estimates o

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (9) Dammit, little-endian systems *are* more consistent!

Working...