> No matter what you do, your estimates will never be accurate.
> When estimating, a different estimate usually means there is a conflicting understanding of what needs to happen.
If all estimates are inaccurate (they are), then two estimates for the same job would be expected to differ, regardless of any conflicting understandings.
The author's view seems to be that estimating is generally best not done. I had hoped there might be some tips on how to make better estimates, or how to use estimates better. Everyone hates estimating, because of the risk of being hoist by your own estimate; but sometimes estimates have to be made, and then it's best made by you, rather than by your boss or sales-dude.
A long time ago I was taught Function Point Analysis. The job is broken down into "functions", which means something like deliverables: screens, reports, inputs, processes etc. Each function scores some number of points; you just add up the points. The number of days per point depends on the coder's velocity and the estimator's bias; given a history of estimates, the estimator's bias can be calculated, and the coder's history yields his velocity. There is also scope for fudge-factors, to account for e.g. complex processing.
In addition to an estimate in days, this process also yields intelligence about your coders and your estimators.
[Edit] Part of the goal of FPA was to facilitate making estimates based on just a functional spec, with no detailed design.
> When estimating, a different estimate usually means there is a conflicting understanding of what needs to happen.
If all estimates are inaccurate (they are), then two estimates for the same job would be expected to differ, regardless of any conflicting understandings.
The author's view seems to be that estimating is generally best not done. I had hoped there might be some tips on how to make better estimates, or how to use estimates better. Everyone hates estimating, because of the risk of being hoist by your own estimate; but sometimes estimates have to be made, and then it's best made by you, rather than by your boss or sales-dude.
A long time ago I was taught Function Point Analysis. The job is broken down into "functions", which means something like deliverables: screens, reports, inputs, processes etc. Each function scores some number of points; you just add up the points. The number of days per point depends on the coder's velocity and the estimator's bias; given a history of estimates, the estimator's bias can be calculated, and the coder's history yields his velocity. There is also scope for fudge-factors, to account for e.g. complex processing.
In addition to an estimate in days, this process also yields intelligence about your coders and your estimators.
[Edit] Part of the goal of FPA was to facilitate making estimates based on just a functional spec, with no detailed design.