

Why you suck at estimating – a lesson in psychology - australis
http://blog.muonlab.com/2012/04/12/why-you-suck-at-estimating-a-lesson-in-psychology/

======
cateye
The real problem is the impossibility to define the requirements in a way that
they can't be misinterpreted.

We (as a industry) tried it with UML and we found out that it is more work
than actually writing the code and it was still useless because there isn't a
possibility to check for errors.

Because of this, "the developers" and the "managers" need to reach an
agreement on a more emotional level where they can trust each other and fill
in the gaps with their expertise and experience.

Just keep on trying to document the requirements more detailed, estimating
more factually will be a waist of time and it will lead to bureaucracy and
mediocre software.

------
dasil003
Yeah you might be getting burned by these, but even if you are very careful to
avoid them, estimating software development in particular is pretty much
impossible for anything beyond trivial. The fractal complexity of software
means there are often unknown unknowns waiting inside various libraries and
architectures that you plan to use. I realize other domains have similar
problems (large construction projects come to mind), but to paraphrase
Dijkstra, no human endeavour spans a greater scale in orders of magnitude than
programming, and it's all just a heap of text with minimal transcription cost!

Given the nature of software, I think that the only sane process is an agile
one, where the estimate and scope is under continual refinement as the project
develops and becomes better understood. Sometimes business requirements
dictate otherwise, but that will always lead to a suboptimal solution.

I think that may be the key reason why I prefer startups to other forms of
programming work: in a startup you can not afford to do anything for ceremony
or to CYA, the focus on optimizing the product must be relentless.

~~~
macavity23
Agree 100%. For those who haven't done Agile estimation before, I strongly
recommend Martin's 'Agile Estimation and Planning' book - quick to read and
lots of good stuff, in particular:

* Write your requirements as 'User Stories' - discrete units of functionality that are as independent as possible and can be developed and tested as a unit. This gives you maximum feedback on how far along you are against your original scope.

* Estimate complexity, not time. For the reasons this guy gives, people suck at estimating how long something takes. However they are better at estimating how complex something is, particularly relative to other similar things. This means you can estimate each story using 'story points' (an arbitrary measure of complexity, relative to other stories), and then be reasonably confident that two stories rated the same are going to take about as long to write. There is some variation here, of course, but averaged out over all your stories you can get quite accurate results, and usually increasingly-accurate as you go along.

* The people making the estimates should be the ones that are going to be doing the work! Seems obvious, but many places have one person (often a manager or team lead) estimate a task, then have the developers build it, and then the manager gets upset that the developers are 'lazy' (i.e. his estimates were rubbish). As the author says, use planning poker with your development team. This can seem like an Agile kool-aid gimmick to those who haven't used it, but it is a very effective way of getting everyone's input. The best developers are often those less likely to volunteer information in a group setting, and this is a great way of getting their opinions without putting them 'on the spot'.

------
thibaut_barrere
(Really) useful resources on estimating:

\- [http://www.mountaingoatsoftware.com/presentations-
estimating...](http://www.mountaingoatsoftware.com/presentations-
estimating?page=1)

\- [http://www.mountaingoatsoftware.com/books/1-agile-
estimating...](http://www.mountaingoatsoftware.com/books/1-agile-estimating-
and-planning)

(I'm not affiliated with Mike Cohn but took his estimating and planning course
and must say it's worth the money).

------
Renaud
I often find that _over-enthusiasm_ for a task can often be a huge factor in
getting estimates wrong: over-enthusiasm will lead to the compound effect of
underestimating past experiences, over-confidence, and, when your interest
wanes, you end up dragging your feet and spending a lot more time doing the
gritty, uninteresting parts of the task.

------
angdis
The other half of the problem is that management (especially nontechnical
"PMP" types) suck at understanding the realities of software development and
obsess too much on deadlines and "accountability" when they would do better to
focus on removing obstacles for the team or, god-forbid, perhaps jump in and
do some of the actual work.

~~~
tagawa
Nooooo, please don't let them get involved in the actual work!

EDIT: Maybe I should politely rephrase that: If they're anything like my
previous non-technical managers, I'd rather they make the most of their
talents elsewhere.

Moving back on topic, the article is worth reading just for the mention of
Planning Poker alone. Another moment of enlightenment for me on HN.

------
mainevent
Wondering whether this article should credit Daniel Kahneman's "Thinking, Fast
and Slow" as these ideas seem to come fairly directly from that book.

[http://www.amazon.co.uk/Thinking-Fast-Slow-Daniel-
Kahneman/d...](http://www.amazon.co.uk/Thinking-Fast-Slow-Daniel-
Kahneman/dp/1846140552)

------
peteretep
Scrum attempts to solve many of these problems, rather than just labelling
them:

[http://www.writemoretests.com/2012/02/estimating-like-an-
adu...](http://www.writemoretests.com/2012/02/estimating-like-an-adult-what-
to-steal-from-agile.html)

------
vacri
Take the 'psychology' out and insert 'software development'. We're actually
really quite good at estimating things in a psychological sense, it just
stands out when we mis-estimate.

