Estimating development time of software is one of my least favorite things to do. Usually, I’m pretty good at it, but that doesn’t change the fact that it’s
- Time consuming
- Often grossly inaccurate
- Usually done while flying by the seat of your pants, with a marginal (at best) understanding of the functionality that you need to estimate.
I’ve always been a pessimistic estimator, and it’s something that people I’ve worked with for a long time understand and appreciate (even if they make fun of me for it, at times).
Some people might think it’s crazy to be a pessimistic estimator, because any estimate that you give to a client that’s padded by 50 or 100% is potentially going to be high. It might be a lot higher than some other shop who might totally low-ball an estimate just to land a contract.
In my opinion, in my way of doing business, the risk of a dissatisfied customer from a blown budget due to a low-ball estimate is significantly greater than the risk of losing a few contracts because of pessimistic estimates.
I would rather estimate high and exceed expectations by coming in well under budget; even if it means that I lose some work along the way because someone felt my estimates were too high.