An older engineer once told me a valuable tl;dr approach to engineering estimates: whatever number you arrive at, multiply it by two.
What We Do and Don't Know about Software Development Effort Estimation
11–20 of 49 posts
Re: What We Do and Don't Know about Software Development Effort Estimation
#12Yet another place where intuitions derived from the normal distribution about the behavior of distributions screws people. An explanation I like, from michaelochurch: Let's say that you have 20 tasks. Each involves rolling a 10-sided die. If it's a 1 through 8, wait that number of minutes. If it's a 9, wait 15 minutes. If it's a 10, wait an hour. How long is this string of tasks going to take? Summing the median time…
[deleted]
Re: What We Do and Don't Know about Software Development Effort Estimation
#13> An implication of these observations is that clients can avoid effort overrun by being less price - and more competence - focused when selecting providers.
I absolutely loved this line.
Re: What We Do and Don't Know about Software Development Effort Estimation
#14Yet another place where intuitions derived from the normal distribution about the behavior of distributions screws people. An explanation I like, from michaelochurch: Let's say that you have 20 tasks. Each involves rolling a 10-sided die. If it's a 1 through 8, wait that number of minutes. If it's a 9, wait 15 minutes. If it's a 10, wait an hour. How long is this string of tasks going to take? Summing the median time…
[deleted]
Re: What We Do and Don't Know about Software Development Effort Estimation
#15An older engineer once told me a valuable tl;dr approach to engineering estimates: whatever number you arrive at, multiply it by two.
"Six to eight weeks" was the default estimate my project managers gave for anything above trivial. Long enough to make the task seem difficult, not too long to scare off the client.
Re: What We Do and Don't Know about Software Development Effort Estimation
#16Re: What We Do and Don't Know about Software Development Effort Estimation
#17An older engineer once told me a valuable tl;dr approach to engineering estimates: whatever number you arrive at, multiply it by two.
That older engineer... was it Scotty?
Re: What We Do and Don't Know about Software Development Effort Estimation
#18I think many and perhaps most poor estimates are caused by initial estimates being viewed as too high for the project, and instead of deciding the project isn't worth doing at its estimated cost, instead deciding the estimates must be wrong in order to align expected project value with expected project cost. Perhaps in a twisted future where we estimate project cost before deciding which projects to take on, we might…
Well, exactly. If I understand the paper, the only condition you need in order to arrive at accurate estimates is the absence of pressure to underestimate.
Re: What We Do and Don't Know about Software Development Effort Estimation
#19Yet another place where intuitions derived from the normal distribution about the behavior of distributions screws people. An explanation I like, from michaelochurch: Let's say that you have 20 tasks. Each involves rolling a 10-sided die. If it's a 1 through 8, wait that number of minutes. If it's a 9, wait 15 minutes. If it's a 10, wait an hour. How long is this string of tasks going to take? Summing the median time…
That's a nice lucid example. Google should hire that guy!
Re: What We Do and Don't Know about Software Development Effort Estimation
#20An older engineer once told me a valuable tl;dr approach to engineering estimates: whatever number you arrive at, multiply it by two.
An even older engineer once told me: Even after you've doubled the estimate, it will still take twice as long as you estimate.