When I worked at a BigCo, we had what we called the engineering estimate multiplier . When asking an engineer how long something will take, you need to apply the following formula to the result.

1. Multiple the integer value by 2.
2. Increment the type of time used in the estimate.

An example of the multiplier in use:

Joe Optimist says it will only take a 4 hours to implement the flibbertywidget feature. A smart engineering manager will take that estimate, apply the multiplier, and get a realistic estimate of 8 days.

Engineers will typically think of the simplest solution for a problem and think of how long that will take to implement without any thought to unexpected issues, bugs, etc. they may run into during implementation.

Successful senior engineers mitigate this much better than junior engineers. A good manager may apply a slightly different multiplier depending on who is providing the estimate. However, be assured a multiplier is always needed.

A real-world example:

I remember running over a feature list we had for an upcoming release. We had about 3 months of development time, and the three of us on the team thought we could definitely get everything done.

Our engineering manager then sat us down with a timeline, and started recording fairly detailed levels of effort (in hours) for the work on the feature list we thought we could complete. We ended up at 300+% utilization for each of us, including pulling in a few other resources for smaller bits.

Progress:

I’ve been getting better and better at this as I continue to work as an indy developer on various projects, including customizations for my own software. The good news is that this helps me manage my schedule and provide accurate estimates for my clients. The flip side of that is my estimates for projects have increased a fair amount.

Recommendation for anyone hiring a developer: beware the low estimate.