Slashdot Mirror
Overconfidence: Why You Suck At Making Development Time Estimates
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.'"
'nuff said.
We've all been under pressure to give our "best" estimates and then some.
Give a realistic estimate? Off to India!
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.
File under 'M' for 'Manic ranting'
Always tripple all estimates. That way you always look like a miracle worker.
If I were God, wouldn't I protect my churches from acts of me?
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?"
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.
I think they finally blocked the APK posts with a HOSTS file.
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
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.
Hofstadter's Law:
It always takes longer than you expect, even when you take into account Hofstadter's Law.
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.
Bye!
I usually take whatever estimate I'm given and change it to the next largest unit and double it. Thus, an estimate of two hours become four days. This is still usually less than the actual time required. And don't even get me started on projecting when some task will be completed as opposed to how much effort will be required. The above alogorithm does a reasonable job at estimating effort actually requied but determining the calendar completion date is a whole different animal.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
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:
Actually, most of those things can be predicted. What is harder to predict is the creative aspect of development. Predicting a civil engineering project, like a bridge, is easy because engineers can compute the number of beams, the volume of concrete, the depths of the footings, etc, and they already have a good idea how construction people will behave, so they can add 5% for vacations, 20% for staffing difficulties, 10% for late trucks, etc. Predicting the creation of a new piece of software is less certain, because so many of those pieces are unknown. You make an initial survey of the requirements, and take an educated guess at what the solution might be, but you know that's never the final picture of the real solution.
If you're on a mature Agile team, you trot out your velocity, map your epics to some t-shirt sizes, and do some simplistic multiplication. But you also know to announce the estimates in terms of your team's delivery dates, and you don't overpromise. At this point, either management trusts your team's reputation and you boldly go forward, or you give them estimates with confidence levels around 20%, because you simply can't be more accurate than that.
If you're on a waterfall team, any software development estimate with an accuracy figure of higher than about 50% should be viewed with suspicion, and anyone claiming 90% or higher should be flagged as a true bullshit artist.
John
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?
I love Jesus, except for his foreign policy.
If you ask any experienced software developer about estimating when the project will be finally completed you will get a blank stare --- for the simple reason that there are always higher mountain to climb, more features to add, more bugs to be squashed, more optimizations to be made, and so on ...
I do not do time estimation --- I do the reverse
I set out a limit on time before I even begin a project
Within that time span I partitioned it into "exploration", "research", "coding", "debugging", "finishing touch" --- and I can terminate the entire project when any part of the partition takes too long, or produce too few result, or both
That's the way I've been using since the late 1970's --- it might not be the best way, but that's my way of accomplishing my projects --- or abandon it before it dragged out way too long
Muchas Gracias, Señor Edward Snowden !
Manager: "We need an application that does X,Y, and Z. When can you have it done?"
Developer: "Well, can you tell me more?"
Manager: "No, time I have a manager's meeting in 5 minutes. Just give a pall park."
Developer:" Ok, umm 3 weeks."
Manager: "THAT LONG?"
Developer: "OK, 2 weeks? Maybe less?"
Manager: "OK"
Later, in the manager's meeting.
Manager:"My developer says he can get it done in less than 5 days."
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
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!