Why Can't Developers Estimate Time?

Art can break rules and you can sell weird color splotches for millions, but the output of your /dev/random will always be worthless.

When I managed a team, I had people put their initial estimates in the tracking tool, and when closing out the item they'd also fill in how long it actually took. Then, some of the report generation tools would let them see how accurate they were. There were no review metrics associated with being accurate, but I found that within a couple of months in a new area, individuals started getting much more accurate without just lamely padding out schedules (their teammates would have called them out, and even I wasn't pointy-haired enough to be fooled that easily). An unexpected bonus is that people also got a lot better at describing their work and investigating the risky bits before throwing something onto the schedule for the sprint.

But, we didn't do this for purely investigative or experimental work (i.e. "try out a new immutable text region design in the editor"). We'd just timebox work like that and evaluate progress to decide whether to keep going or not.

You can certainly find better practices in some organizations, but in many organizations, a certain team gets tasked with completing a certain assignment by an arbitrary deadline and no attempt is made to reconcile the triple constraints with reality.

In a context like that, developers may not be asked to make estimates, and if they do make estimates they don't believe that they'll be taken seriously. So they never develop the chance to learn how to estimate.

The accuracy of estimation also depends on the context.

If, for some reason, I had to fix a difficult-to-reproduce bug in a large system written in COBOL that runs on a mainframe, I'd have very little idea of how long it would take me to learn COBOL, understand the codebase, figure out the tools, and track the problem down. A COBOL jock would obviously do better.

On the other hand, I've worked on greenfield well-specified business CRUD apps based on a correctly aligned framework where I could estimate that something would take 21.25 hours and I'd really get it done in 19.75 or 22.50.

I've met developers who will absolutely refuse to estimate anything but I think more often developers don't believe their estimates will be listened to.

The good news for both developers and managers is that estimation is a learnable skill. If you get in the habit of making estimates and testing them, you'll get better amazingly fast. See the classic book

http://www.amazon.com/Software-Estimation-Demystifying-Pract...