Software Estimation

Consider the following conversation:

Boss: "What is the weather forecast for tomorrow?"
Meteorologist: "Overcast with showers."
Boss: "Hmm, that is unfortunate. I wanted to play golf. Can you give me a better prediction?"
Meteorologist: "Well, OK, how about: partly cloudy with sunny spells?"
Boss: "Thanks, that's much better!"

Pretty bizarre, huh? How about this:

Project Manager: "How long to do the first phase of this project?"
Software Developer: "Umm, 10 months. We'll need 8 developers."
Project Manager: "That's not good enough, I can't sell that to upper management. Can you give me a better answer?"
Software Developer: "Maybe we can do it in 8 months, with 6 people." (thinks: "We can start working overtime if things go wrong...")
Project Manager: "How about 6 months? You all could work overtime..."

The latter conversation happens all too often, unfortunately. One of the problems with software projects is that they are almost always late, and estimation is one of the reasons. Interestingly enough, software developers are usually pretty good at estimating how long their work will take, but a realistic estimate is not always what managers want. So, eager to please, the developer gives an estimate that the manager will like. If it turns out that the original estimate was too pessimistic, all will end well. If the original estimate was too optimistic, then real problems develop.

Developers and managers are equally to blame for this practice. Developers should have the courage to give their manager an honest answer. Managers should be willing to accept realistic estimates, otherwise they cannot plan a project properly. If it means being the messenger of bad news to their manager, well, that's the manager's job...

Please send comments to