[marshmallowmad]

I don’t agree that trying to estimate things is bad as the author suggests. If you are perceptive and want to get better at it, then there’s a decent chance you will. Estimates also help us timebox work. They can help us give an objective view of when we should start exploring functionality tradeoffs. This article sounds like a lot of whining about not wanting to do something because it’s difficult.

I will say I think that holding people to estimates is not fair because it doesn’t necessarily correlate with productivity/value added. When asked for estimates my general rule is: take a conservative estimate and double it.

[fhd2]

Let's call it what it is: Guessing. Guessing can be incredibly useful, and I've never seen an engineer or PM refuse to _guess_ (or "project"), because that implies they won't be held to it.

[commandlinefan]

> trying to estimate things is bad

I've never, not once, in 30 years of developing software professionally, seen a feature request that was well defined enough to estimate to any level of accuracy. The definitions are always so vague that the answer could range from "this is already done" to "this is not possible". The hard part, and what takes the most time, is always working out exactly what they want - and that's what they want (and expect) an estimate of. "Estimate how long it's going to take you to figure out what exactly it is that I'm asking for."

[doctor_eval]

But then there’s Hofstadter’s law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

https://en.m.wikipedia.org/wiki/Hofstadter%27s_law