Ask HN: Do you have faith in any time estimating system?
Is there a good reason to force engineers to estimate how long a ticket will take to complete?
Personally, 90% of the time I'm just making things up if I need to estimate how long a feature will take to implement. The only time I'm confident is if I can visualize the line of code that I know is causing a bug. In that case the ticket usually takes 5 - 10 minutes to fix. But sometimes I'm wrong, and that line is causing a problem because of a bigger flaw I didn't realize.
Can I just admit I have no idea and just write down random numbers that aren't obviously wrong?
Do time estimates truly exist just to make business side employees feel good? Do you see a future where companies can negotiate funding without relying on this inherently flawed (and fraudulent?) tool?
11 comments
[ 3.3 ms ] story [ 32.2 ms ] threadIn my experience, the desire for a time estimate often stems from an underlying desire for control (mostly over a budget). That desire is understandable. As an example, if you put yourself in the shoes of a customer wanting your car repaired, you will most likely have a strong desire to know what it will cost before the actual repair is carried out. That desire is justified for a number of reasons, the most important one being that you need a basis for a decision for or against the repair. It wouldn't make much sense to invest more than the car is worth, for instance.
Now, it's not always possible to state a price, especially if what you're building (or repairing) is subject to uncertainty. In that case, I'd recommend that you provide your customer (or boss or investor) with another measure of control. In agile development, the easiest thing you can do is shorten your cycles and give them full transparency over your progress and the ability to stop or change direction at each product increment. This would be analogous to the repair shop offering you a phone call after they got a better diagnosis of the problem for which you paid only a small amount and then you get the chance to decide again, maybe with a better estimate of the overall repair cost.
So when you ask FogBugz when the next milestone will be completed, it doesn't just add up the estimates. Instead, for each ticket it finds similar tickets with similar estimates, and picks from that list one of the actual reported times. It then adds up those reported times to make a guess at a real estimate. It then runs the same simulation 100 times to show you how likely you are to hit various dates.
Seems fair enough to me, probably because thats what I do. At the end of the day nobody knows how long it will take unless they can tell the future.
I think scope is something my estimates are missing, for example if some one says their roof is leaking they may just need a broken tile fixed or they might need a new roof, without a proper scope of what I'm estimating the estimate is too open ended.
So are you saying we should amortize the complex cases by overestimating how long the basic tasks take?
That can work for a mechanic because it’s 100+ standard cases to every complex case.
This has worked with pretty good consistency in the past. I believe that a good deal of the value comes from factoring in the estimate where everything goes wrong. You can also then specifically work to prevent the things you’ve thought about going wrong from occurring.