Yes, Estimate Software Projects

Yes, Estimate Software Projects
blog.pragmaticengineer.com

Is this why so many Apple products have been increasingly low-quality? Instead of committing to quality, they commit to arbitrary dates because some bean counter decides quarterly profits needed to be higher.

I don’t disagree that we should estimate, but I think we should be realistic about just how difficult estimating software projects is, especially now that we’re “agile”, which really means “there aren’t any explicit requirements but there are requirements, we just don’t know what they are and also they change every sprint so good luck”.

If we want to estimate software, we need to have more predictability. I can estimate that it takes three days to fix a bug, but what happens when I pull those covers back and see an unholy Eldritch abomination? I could redo my estimate, but what if I run into an arbitrary quarterly profit-driven date? “Well, just get it done.” Then we nail some more legs to the dog and the cycle continues.

In Thinking Fast and Slow, Daniel Kahneman offers my favorite object lesson on the topic:

http://txti.es/kahneman-outside-view

He sums up:

This embarrassing episode remains one of the most instructive experiences of my professional life. I eventually learned three lessons from it. The first was immediately apparent: I had stumbled onto a distinction between two profoundly different approaches to forecasting, which Amos and I later labeled the inside view and the outside view. The second lesson was that our initial forecasts of about two years for the completion of the project exhibited a planning fallacy. Our estimates were closer to a best-case scenario than to a realistic assessment. I was slower to accept the third lesson, which I call irrational perseverance: the folly we displayed that day in failing to abandon the project. Facing a choice, we gave up rationality rather than give up the enterprise.

The suggestion that the enterprise should have been abandoned all together can be misinterpreted as fatalistic, even nihilistic. I take it to mean that you've got to do your research (the outside view), rigorously define your MVP, and then work from there. If your deadline is fixed, be ready to scale back.

His distinction between the inside and outside view is the key. For a project to have any hope of realistic timelines, it needs to be understood and the outside view needs to be applied.

Having to guess how long a project will take is still very scary for me. Is there any way to get over the fear of others disagreing? I always feel like I'm about to embarrass myself by either estimating to high or to low...

Surface uncertainty rather than hiding it, and fight for the time to resolve uncertainty before committing to a timeline. Fight to shrink the assignment if it seems too large.