Why you suck at estimating – a lesson in psychology
blog.muonlab.com
Why you suck at estimating – a lesson in psychology
1–10 of 11 posts
Re: Why you suck at estimating – a lesson in psychology
#2I 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.
Re: Why you suck at estimating – a lesson in psychology
#3Scrum attempts to solve many of these problems, rather than just labelling them:
http://www.writemoretests.com/2012/02/estimating-like-an-adu...
Re: Why you suck at estimating – a lesson in psychology
#4Yeah 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.
Re: Why you suck at estimating – a lesson in psychology
#5Take 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.
Re: Why you suck at estimating – a lesson in psychology
#6(Really) useful resources on estimating:
- http://www.mountaingoatsoftware.com/presentations-estimating...
- http://www.mountaingoatsoftware.com/books/1-agile-estimating...
(I'm not affiliated with Mike Cohn but took his estimating and planning course and must say it's worth the money).
Re: Why you suck at estimating – a lesson in psychology
#7The 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.
Re: Why you suck at estimating – a lesson in psychology
#8Wondering 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...
Re: Why you suck at estimating – a lesson in psychology
#9The 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.
Re: Why you suck at estimating – a lesson in psychology
#10The 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.
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.