We’ve all been there. “ How long will this take to get done?”. The answer they are looking for is “ by this afternoon,” but most often the real answer is longer than that, usually much longer. The real answer is, “I don’t know.” But you have to answer. Often you will hear tales of people rolling dice or making something up or saying “ six weeks” no matter what. In the end, you can’t know for sure because you’ve never done that project before, and so you make your best guess and it works out somehow most of the time.
But a lot of developers and managers fail to realize that there are two different kinds of answers you can give. If it is Monday, you can say, “ I’ll have that done by Friday.“ Then you work like crazy, and just before you go home on Friday, you deliver what you promised.
The other type of answer you can give is, “That will take 40 hours.” And so if it is Monday, and you say that, then the manager will hear “ I’ll have that by Friday.” So then you go and you work like crazy, and just before you go home on Friday, you deliver what you promised. But when you’re done clocking all your time, you put in 50 hours to get the project done. That’s a 25% overrun, and your manager wants to know what happened and why you took more time than you said.
There are a lot of things going on here — but the point I want to make is that there is a difference between an estimate and a target. An estimate — “How many hours is this going to take?” — is very difficult to get right. There are always unknown unknowns that enter in to make the total number of hours that something will take. We are notoriously bad at making estimates. There are a lot of reasons for that, but the fact remains that we are not capable of making accurate estimates. But “I’ll have that by Friday” is more comfortable to say because you have flexibility in the amount of work it takes to hit that target.
But note well that an estimate is not a target. A target is when you say, “ I’ll have that by Friday.” Saying that on Monday morning is not the same thing as saying, “It will take 40 hours to do”. It’s a very, very different thing. Saying “ I’ll have that by Friday” actually means “ I’ll do whatever it takes — put it however many hours it takes — to get this done by Friday.” It might take 20 hours. It might take 60 hours. But you didn’t say anything about how many hours it would take; you gave the target point when it would be delivered.
So if you are a manager, recognize the difference between a target and an estimate. If you are asking for an estimate, understand that software estimation is still something even the most seasoned developers do very poorly. If you are asking for a target, realize you may be asking someone to put in a lot of hours to hit that target. Or not — maybe they say “Friday,” and it only takes half an hour. Who can say for sure? If Friday is good enough, then you shouldn’t care how many hours it ends up taking either way.
And the one thing you shouldn’t do is ask for an estimate, take it as a target, and then get upset when the developer hits the target but runs over on the hours.
Targets are not estimates, and estimates are not targets. Understand the difference, and you’ll have happier developers and happier managers.
This article was originally published at http://www.codingindelphi.com on February 1, 2015.