This one is my favorite: http://www.quora.com/Engineering-Management/Why-are-software...
Poor developer estimates, a.k.a. guesstimation
11–20 of 72 posts
Re: Poor developer estimates, a.k.a. guesstimation
#12I recently read Software Estimation (Steve McConnell, author of Code Complete). My main takeaway was to distrust developer intuition and instead build estimates from data. One example is to look at the duration of past projects of "similar size" (still requires some qualitative analysis). Another example is to count the number of distinct "features" or "components," and build an estimate from those. Both of these sti…
One important lesson to take from McConnell's book is that you should not rely on a single sort of estimation. Serious estimators will estimate in distinct ways and then compare the outcomes. If they are widely divergent, it's time to investigate why.
Re: Poor developer estimates, a.k.a. guesstimation
#13This one is my favorite: http://www.quora.com/Engineering-Management/Why-are-software...
You can make the argument that this story reveals important features about taking estimation seriously.
1. The author gave a point estimate, instead of a range.
2. The author didn't decompose the task. They took the highest level view and performed a back-of-the-envelope calculation. A closer reading of a differently-scaled map would have revealed many of these delays, giving at least one or two orders-of-magnitude changes in the initial estimate.
3. The author did not seek out historical data or models for this kind of project. Hiking and bushwalking are well-known. There are tables of travel time which can be used to establish a better idea of the outcome. Experienced walkers could have been sought out for their expert judgement of the initial estimate.
It is not as good a parable as people make it out to be. The problem was not an unknown or unknowable problem domain. It was due to ignorance of the basics of estimating.
Re: Poor developer estimates, a.k.a. guesstimation
#14I've always found this article -- "Evidence Based Scheduling" -- by Joel Spolsky to be rather compelling: http://www.joelonsoftware.com/items/2007/10/26.html I'm curious if anyone else has tried it?
As part of my research on estimations I've been working through Edward Merrow's book Industrial Megaprojects. It's based in part on a large database of megaprojects that his firm consulted on.
He considers Monte Carlo-based methods to at best pointless, at worst harmful to outcomes (p 324):
The average megaproject cost estimate when Monte Carlo simulation
was used overran by 21 percent, with a standard deviation of 26
percent and with a sharp right skew. When Monte Carlo simulation
was not used, teams were actually more sensitive to basic risks as
they set contingency.
... The use of Monte Carlo simulation has no relationship to success
of megaprojects or any of our other five figures of merit of projects:
cost growth, cost competitiveness, schedule slippage, schedule
competitiveness or production attainment.Re: Poor developer estimates, a.k.a. guesstimation
#15Earlier quoted context omitted.
This is basically your solution: http://imgur.com/YNmKId9 PHB: Use the CRS database to size that market. Dilbert: That data is wrong. PHB: Then use the SIBS database. Dilbert: That data is also wrong. PHB: Can you average them? Dilbert: Sure. I can multiply them too. ----- I kid (sorta). It misses the core issue, why are developers estimates so terrible, 3 terrible estimates don't make a "good" one. The post hits on…
You are absolutely right. It's impossible to estimate how long it will take to complete something you have never done before in your life. Unless the new code being written is absolutely trivial, estimates are going to be guesses, at best. The only half-decent solution I found so far is iterative development. Take a feature and break it down i to big rocks. Further break down the big rocks into little chunks - each t…
> Take a feature and break it down i to big rocks. Further break down the big rocks into little chunks - each that you estimate would take you less than a day to complete.
Experimental psychologists have found that decomposing tasks increases estimate accuracy, regardless of how or why the task is decomposed. It's called the "unpacking effect".
http://www.sciencedirect.com/science/article/pii/S0022103103...
Re: Poor developer estimates, a.k.a. guesstimation
#16I recently read Software Estimation (Steve McConnell, author of Code Complete). My main takeaway was to distrust developer intuition and instead build estimates from data. One example is to look at the duration of past projects of "similar size" (still requires some qualitative analysis). Another example is to count the number of distinct "features" or "components," and build an estimate from those. Both of these sti…
My main takeaway from the McConnel's book has been not to provide an estimate as a single point number (say something like it will be done in 5 weeks) but rather as a range (say something like 5-8 weeks), as providing a single point number would give the impression that it is the target date (while it is not). But unfortunately most of the
times all I have got is blank stares when I give estimates as a range and a question why don't you give me the time it takes to finish :(. Wish more number of people who do project management read at least 1st two parts of McConell's book on software estimation.
Re: Poor developer estimates, a.k.a. guesstimation
#17I recently read Software Estimation (Steve McConnell, author of Code Complete). My main takeaway was to distrust developer intuition and instead build estimates from data. One example is to look at the duration of past projects of "similar size" (still requires some qualitative analysis). Another example is to count the number of distinct "features" or "components," and build an estimate from those. Both of these sti…
My main takeaway from the McConnel's book has been not to provide an estimate as a single point number (say something like it will be done in 5 weeks) but rather as a range (say something like 5-8 weeks), as providing a single point number would give the impression that it is the target date (while it is not). But unfortunately most of the times all I have got is blank stares when I give estimates as a range and a qu…
I hope you'll keep insisting on giving ranges.
Re: Poor developer estimates, a.k.a. guesstimation
#18This one is my favorite: http://www.quora.com/Engineering-Management/Why-are-software...
You can make the argument that this story reveals important features about taking estimation seriously . 1. The author gave a point estimate, instead of a range. 2. The author didn't decompose the task. They took the highest level view and performed a back-of-the-envelope calculation. A closer reading of a differently-scaled map would have revealed many of these delays, giving at least one or two orders-of-magnitude…
Your issues are exactly why that story is a great parable for poor project planning.
Re: Poor developer estimates, a.k.a. guesstimation
#19Earlier quoted context omitted.
You can make the argument that this story reveals important features about taking estimation seriously . 1. The author gave a point estimate, instead of a range. 2. The author didn't decompose the task. They took the highest level view and performed a back-of-the-envelope calculation. A closer reading of a differently-scaled map would have revealed many of these delays, giving at least one or two orders-of-magnitude…
Your issues are exactly why that story is a great parable for poor project planning.
Absolutely. But it's often trotted out as a parable for why project planning is pointless, or impossible.
Which is a very different conclusion to draw.
Re: Poor developer estimates, a.k.a. guesstimation
#20Also be aware of the selection bias when it comes to estimations. The companies A, B and C all put in estimates for a product based on similar premises. Company C gets selected because their estimate is the lowest. This could be because company C is the best and can do the work quicker but it is also possible that company C has just made a low estimate pretty much by chance. Estimates that are wrong (lower than the a…
I think you're mixing bids with estimates.