Ashley Moran just wrote an interesting article about why developers can’t estimate time.
Something most developers find hard is estimating the time something will take.
If it’s something you have done before, a repeatable task, then it’s easy – although most of the time things take longer than you think they will when you think it through in your head and quite often it turns out to be more complicated than you thought when you get into it or you hit a bug of some kind that you end up having to debug which takes a long time and compounds the issue.
Sometimes the problem of bad estimates is made worse is when estimates (which are at the end of the day an educated guess) are taken as a promise and therefore if it takes longer then there is a feeling that it should have been done quicker.
I particularly found these quotes interesting and amusing:
We can’t estimate the time for any individual task in software development because the nature of the work is creating new knowledge.
Rule of thumb: take the estimates of a developer, double it and add a bit
The double-and-add-a-bit rule is interesting. When managers do this, how often are tasks completed early? We generally pay much more attention to overruns than underruns