

We don't need no stinking estimates - enkiv2
https://medium.com/backchannel/estimates-we-don-t-need-no-stinking-estimates-dcbddccbd3d4

======
geebee
This is a good article. I didn't know about the #NoEstimates hashtag. It's
been interesting to read.

In general, I think that any discussion that informs people about the
difficulty of making estimates where software is concerned is a good thing.
I'm not delighted that the term "NoEstimates" sounds a little radical and
defines itself (as the post mentioned) by what it is not. I do think that
"nosql" may have harmed itself a bit that way as well, even though it really
means "maybe not always sql depending on your problem", which is pretty good
advice.

I think the real problem, also mentioned in the article, is this: "Managers
have a habit of treating developers’ back-of-the-envelope estimates as
contractual deadlines, then freaking out when they’re missed. And wait,
there’s more: Developers, terrified by that prospect, put more and more energy
into obsessive trips down estimation rabbit-holes."

This has come up in previous discussions, and it's an important point. The
agile manifesto recommends we value "Customer collaboration over contract
negotiation". But this blog entry about estimates identifies the problem here
- casual estimates later become contractual deadlines (even if you aren't in a
formal contract situation, even if it's all internal, your name next to a task
and deadline = contract). So in this sense, the movement away from waterfall
can simply lull developers into a casual "back of envelope" estimate that
turns into "but you said you'd get it done by friday!" It's almost enough to
get you to want to go back to waterfall. After all, if you're going to be held
to a deadline, it helps to have a document specifying _exactly_ what you would
or wouldn't do. At least then (since specs always change), both of you are
perpetually "in breach."

Within this context, yeah, I can see why some people would want to just do
away with estimates. Unfortunately, I can't quite see that happening. If
people are trying to decide whether to fund a project (or budget for it), "how
long, roughly, will this take, and how much, roughly, will it cost" is
reasonable. Of course, what "this" is needs to be defined, but not to
waterfall levels of detail. The key is probably a better understanding of what
these estimates really mean and how they should be interpreted by an
organization.

