What We Do and Don't Know about Software Development Effort Estimation
1–10 of 49 posts
Re: What We Do and Don't Know about Software Development Effort Estimation
#2There is mention of tools like group estimates which improve the estimation effort (according to the article).
There isn't much mention of the estimates you can go for:
1) Accurate but not reliable
2) Reliable but not accurate
Re: What We Do and Don't Know about Software Development Effort Estimation
#3IMHO it is quite easy to make a reliable estimation of well-planned project. However it is extremely difficult to plan the project more than one step ahead of what is already done... This is why agile development is so popular.
In general when under-estimating the project you can make it:
1) on time and within planned resources,
2) with all the planned functionalities and
3) without sacrificing quality.
Pick any two.
Re: What We Do and Don't Know about Software Development Effort Estimation
#4IMHO it is quite easy to make a reliable estimation of well-planned project. However it is extremely difficult to plan the project more than one step ahead of what is already done... This is why agile development is so popular. In general when under-estimating the project you can make it: 1) on time and within planned resources, 2) with all the planned functionalities and 3) without sacrificing quality. Pick any two.
> IMHO it is quite easy to make a reliable estimation of well-planned project.
Evidence suggests otherwise. Sure you can estimate +/- 100-200% early on but that isn't what anyone is aiming for in a software project. Even detailed plans of repeatable (non-trivial) software projects do not result error bars that anyone really desires.
Re: What We Do and Don't Know about Software Development Effort Estimation
#5I 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 discover our estimates are much better.
A related pathology is trading technical debt for speed, every time, on every project. The debt will be paid.
Re: What We Do and Don't Know about Software Development Effort Estimation
#6Yet 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
expectancy, we get a sum 110 minutes, because the median time for a task is
5.5 minutes. The actual expected time to completion is 222 minutes, with 5+
hours not being unreasonable if one rolls a lot of 9's and 10's.
This is an obvious example where summing the median expected time for the
tasks is ridiculous, but it's exactly what people do when they compute time
estimates, even though the reality on the field is that the time-cost
distribution has a lot more weight on the right. (That is, it's more common
for a "6-month" project to take 8 months than 4. In statistics-wonk terms,
the distribution is "log-normal".)Re: What We Do and Don't Know about Software Development Effort Estimation
#7I 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…
You've worked on one of those projects too, eh? I call them pony projects, as in I want a fucking pony...
People have a recurring delusion that the world is shaped by their wants.
Re: What We Do and Don't Know about Software Development Effort Estimation
#8Software effort estimation methods fail because they ignore the margin of error. In Mathematics, engineering and statistics a result does not mean anything if it does not include the margin of error. One month may be one month if the margin of error is one day, and one month may be one year if the margin of error is one year. Classic estimation techniques like Cocomo or Albrecht Function Points ignore this fact. They have no mathematical rigor. If presented with mathematical rigor they would be absurd, because their margin of error is between 100% and 600%. Classic software effort estimation techniques are harmfull and dangerous, because ignoring the margin of error they invite to make decisions that ignore existing risks. No automatic method can replace human experience and wisdom. They have not bound margin of error too, but at least they do not pretend to hide existing risks.
Re: What We Do and Don't Know about Software Development Effort Estimation
#9Often a technical realistic schedule is derived and presented, but the business side deems the project cost is too high and asks the schedule to be "optimized." The optimistic scenarios of the schedule is adapted and revised. Of course reality sets in when the project goes forward and it ends up taking as much time as predicted.
Re: What We Do and Don't Know about Software Development Effort Estimation
#10IMHO it is quite easy to make a reliable estimation of well-planned project. However it is extremely difficult to plan the project more than one step ahead of what is already done... This is why agile development is so popular. In general when under-estimating the project you can make it: 1) on time and within planned resources, 2) with all the planned functionalities and 3) without sacrificing quality. Pick any two.
> IMHO it is quite easy to make a reliable estimation of well-planned project. Evidence suggests otherwise. Sure you can estimate +/- 100-200% early on but that isn't what anyone is aiming for in a software project. Even detailed plans of repeatable (non-trivial) software projects do not result error bars that anyone really desires.
I don't know that I'd say it's easy, but it is certainly possible. The big takeaway from the article that I agree with is that historical data significantly improves estimates. If you know that e.g., the last 5 projects took an average of x weeks on the authentication layer, then it's likely that your project will take somewhere around the same time.
The problem is that most companies don't record this data. Start today!