An experienced project manager I used to work with claimed that he
took the programmers’ time estimates, multiplied by pi and converted to
the next time magnitude to get the true number. 1 day converts to 3.14
weeks. He had learned the hard way that programmers are bad at estimating times.
To get a more precise conversion, I’ve created a translation table for
programmers’ time estimations, trying to narrow down where things go
wrong.
| Estimate | The Programmer Thinks | What the Programmer Forgot | Actual Time |
|---|---|---|---|
| 30 seconds | There’s just a small change to the code to be done. I know exactly what to type and where. It takes 30 seconds to type. | Time for starting the computer, the development environment and getting the right source. The time to build, test, check in and document the fix | 1 hour |
| 5 minutes | It’s a minor thing, I just have to look up the exact syntax on google and fix it. | It’s quite rare to find exactly the right information on the first try. Even if it is found, it probably needs some adjustments before it works. Add time for building, testing etc. | 2 hours |
| 1 hour | I know how to do it, but it’s some code to write so it will take some time. | 1 hour is too tight to have any margin for unforeseen problems. Something always fails. | 2 hours |
| 4 hours | It’s some code to write, but I roughly know the step. I know the Wizzabanga module of our standard framework can do it, but I have to check the documentation on exactly how to call it. | This is probably the only realistic estimation. It is large enough to have some margin for unexpected problems, while the task is still small enough to grasp. | 4 hours |
| 8 hours | I first have to refactor the Balunga class into two, then I’ll add a call to the Wizzabanga code and finally add the new fields to the GUI | There’s a lot of dependencies on the Balunga class from different parts of the system. About 40 different files have to be adjusted. The newly added field in the GUI has to be added in the database as well. 8 hours is too large to grasp completely. There will be more steps than the programmer thought of when estimating. | 12-16 hours |
| 2 days | It’s really quite a lot to code. I have to add some new tables to the database, a GUI for those and then the logic to read and write data to the tables. | 2 days of work is too large to overview for most developers. There will surely be things that are missed. Not just small things, but entire major pieces of functionality required will be forgotten during the estimation. | 5 days |
| 1 week | Ouch… that’s a HUGE task. I don’t have a clue on how to do it, but I can’t say I don’t know. One week should be enough, I hope, I really hope, but I can’t ask for more or they’ll think I’m not competent enough. | The task is way too large to get an understanding of for most programmers. It has to be sent back to an architect that can help splitting it in smaller parts and provide some direction how it should be solved. The architect might find a simple way to do it – or find that there’s a lot more work than expected. | 2-20 days |
Time estimation is hard. Every programmer has an interval where the estimations are realistic. Going below that interval means that the overhead (building, testing checking in code) was overlooked. Going above that interval means that the task is too large to overview.
For junior developers, the interval might even be non existing. They overlook the overhead while on the same time any non-trivial task is too large for them to overview. I’d say that an experienced developer should get anything between 0.5 hours and 24 hours right. Above 24 hours a breakdown is needed. It can be done in the head and then summed to 60 hours by the developer – but even someone experienced need to have manageable chunks to think of.
It is also important to understand that experience in programming is not the same as experience in estimation. A developer that’s not involved in the estimation process won’t get good at estimation. Also if actual time spent is never measured and compared to the estimates, there is no feedback to learn from.
Eventually, every programmer will have use for estimation skills. To prepare for that, decide when things are done for each task you take on. Then estimate the task before starting. Finally count the time spent and compare that to the estimate. Also compare what you actually had to do to your own definition of done. That way you’ll improve both your understanding of all the details involved in a task, as well as improve your estimation skills.
A decent antidote to optimism.
Adding together the estimated times for all tasks then adding a percentage for slippage is, I understand, a technique used in project management.
nice article…things are not exactly that they look…:)
Great article. I especially like the conversion of time > 4 hours. I tend to round everything below up to a half day as nothing ever takes less than one half day.
I completely agree that this is a skill one can build up, too often techies feel that it takes the time it takes. “How long time does it take to catch a fish”. The problem is that a fisherman can probably tell you while the hobbyist may not know, so as professionals we ought to be able to give good estimates.
Hofstadter’s Law (“It always takes longer than you think even when you take Hofstadter’s Law into account!”) was published something like 30 years ago yet people are still proposing that time estimates have any place in business?
Sure we are as long as the customer wants to know how much he will need to pay we will continue coming iup with estimates and thrust me no client will multiply his budget by pi. There must be a contingency but what is being proposed here will simply throw you out of business especially with all the bullies that think they can do it in even a shorter time than possible hence competing against potential accurate estimates.
I read a paper where they studies this rigorously. They found that small estimates from developers were invariably underestimates (as you predict), middle estimates were right on, and high estimates were overestimates. So, according to that study (which was pretty large), your rule is wrong on the high end. You need to tone down huge estimates from developers, because things aren’t really as bad as they think they are.
That paper would be really interesting to read. I just made my numbers up myself based on my own subjective experience. Do you have a reference to the paper?
Depending on how you define the “high end” I think I did take into account that high estimates often are a sign of great uncertainty rather than great complexity. “1 week” = “2-20 days” means that it could be worse but it could also be easier.
Without having read the paper you refer to, I’d guess that it shows that the average outcome is lower than the average prediction for high estimates. But if the variance is taken into account, I’d guess that it will show a large spread in the outcome for the high end estimates.
Do you remember if there was any discussion on the variance in the paper?
We have built a computerised estimating system that in practice gives results as reliable as a developer when suitable information is entered – Its core algorithm is based around a random number generator :)
Nice article
Just multiply how long you think it will take by a factor of 3.
For small estimates the correct multiplier is e**pi (~23) for everything else p**e (~22.5). These mults are taking meetings into consideration… The resulting estimation correctness is better than 0.6, and this is a big progress from random number generator that I’ve used 10 years ago.
Our rule of thumb for software estimates is to double it and change it to the next unit higher unit of measure.
Example: 2 days means 4 weeks.
Back in the days (by which I mean the ’80s) at IBM, the statement was that in order to estimate development time, you first made what you considered to be a reasonable estimation, then upgraded the unit and multiplied by two. Therefore:
1 minute = 2 hours;
1 hour = 2 days;
1 day = 2 weeks
…and so on. God help you if anyone estimated six months!
When asked for an estimate, I think (but do not say) one of two things. For most situations, I think: “It’ll take as long as it takes, and it’ll take longer if you keep bothering me”. For situations in which management wants it done in an unrealistic timeframe, I think: “I just need a few minutes to duck into the men’s room and pull a miracle out of my ass”.
Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1125
I think your estimates are about right for bug-fixes or small application tweaks, but no good for new system, application or even major feature developments.
And why stop at one week. Sometimes one has to estimate 3 months for a big job, then when you spend a couple of days thinking about it, something complex drops out, and it turns into 3 days work and a couple of days testing!
Great article! I’d broadly agree with most of the estimates. Interestingly, with the only reliable estimate being 4 hours, mabe the lesson here is to break every single large task down into 4 hour chunks…?
In my first ever job my boss explained what I’ve found to be an incredibly useful tool for estimating. You come up with your initial estimate, then think: “How likely is this to to over-run? How much could it over-run by?” Then think: “How likey is this to under-run? What’s the quickest it could be done by?” Then take a figure somewhere between the two. It’s almost always a lot longer than the initial estimate.
The evolution of estimation …
Method A: “Use Your Gut / Stroke Your Neck Beard”
Process: Estimate in arbitrary blocks of time using divining rods, gurning and an error-correction multiplication constant. Tell people around you what they want to hear. Result: every task is Russian-Roulette, the meaning of integrity & reliability is never comprehended.
Method B: “Brogrammers & Excessive Layers of Middle Management”
Process: Estimate in points, and use historic evidence to translate points to hours. Result: Initially 0% accurate but after a year of logging this method will be “workable”, i.e. just in time for the Brogrammer to move to his new job in iOS or HTML5 dev.
Method C: “Don’t Estimate, Don’t Ask For Estimates”
Process: Tell them when it’s done, or when it needs to be done by (and what are the priorities, and what are the consequences of failure). Embrace incremental, the “power of now” and the benefits of feature shrink. Results: 100% accuracy, 100% rational.
Method C is really romantic. But in real life the customer wants to know if the x-mas upgrade, really is ready for end november and not finished in the middle of february.
Beside that the estimates also are a motivational factor and a way to make sure that he project doesent take 100 years to complete. Since the programmers work towards a goal, “This task is to be finished in 1 hour” he don’t sit and work with it for 4 hours because “it is finished when it is finished”
Then sometimes corners have to be cut and the task is made the way it could be in maybe 1½ hour.
The thing with estimation is that people think of it as a promise where they should think of it as a qualified guess on where you can base cost and deadline. If then project leader and the customer understands this there is no chance of loosing integrity.
A way to manage deadlines are agile development methods, maybe where you move release dates closer together so you always have a working release.
“But in real life the customer wants to know if the x-mas upgrade, really is ready for end november and not finished in the middle of february.”
I have found this not to be resemblant of real life. In real life it’s the promise of an upgrade by christmas that can cripple your ability to produce–not inherently impatient customers.
Pingback: Friday links 34 « A Programmer with Microsoft tools
I usually estimate the implementation time only, in detail, breaking up what needs to be done to individual methods, then multiply it by 2.2 if it’s something on a product and with a technology I already know, or by 3 otherwise. It almost always works.
The factors are the result of several years of experience gathering and adjustments. They seem to work well regardless of the language or particular technology. They even work when the task at hand is about doing maintenance on extremely ugly legacy code – in such cases, the initial implementation time tends to be disproportionately high, because any small change requires touching tons of code.
Pingback: Professional Developers Estimate Times | Passion for Coding
My time table is always +/- 1 of whatever unit of measure I used. If I say 3 hours, that’s 2-5 hours. If I say 6 days, that’s 5-7 days. If I say 1 week, that’s 0-2 weeks. If I say 3 months, that’s 2-4 months.
I don’t use +/- minutes because I just estimate it as “under an hour” which still buys me 2 hours.
When a customer (or a manager) asks “How long will it take?” to a programmer, there is a huge gap between what the programmer and the customer see behind the word “it”. The programmer thinks of “it” in technical details, and thus analyzes the steps to arrive to a workable solution, maybe in a limited context, in development environment. The customer is only interested in the result, not the steps to achieve it, and thus expects that the solution will be deployed, fully functional and without obvious bugs. Also, the problem to solve is usually underspecified, since problems tend to disappear once they are described with the right words.
To estimate a fuzzy task, it is much easier, and surprisingly, more accurate, to provide fuzzy estimates, by providing orders of magnitude for each task:
h+ = one or several hours (but less than a day)
d+ = one or several days (but less than a week)
w+ = one or several weeks
This type of evaluation represents the uncertainty more accurately:
* no task worth discussing takes less than 1 hour
* a simple task may take from 1 hour to 1 day
* a complex task (or aggregates of simple tasks) may take from 1 day to 1 week
* aggregates of complex tasks may span multiple weeks
Using this system, it is easier to justify to a customer that to achieve a certain result, several days will be needed, by listing the tasks required to reach a working solution with their order of magnitude. For example:
[d+] goal
[h+] simple task A
[h+] simple task B
[h+] simple task C
Although A, B and C are simple enough, it will take at least one day to reach the goal, but probably no more than one day in this case.
This image sums up my thoughts on estimating pretty well: http://cdn.memegenerator.net/instances/400x/27924530.jpg
Nice read, I was recently looking for how a developer can estimate in more realistic way and I found this wikipedia article http://en.wikipedia.org/wiki/Software_development_effort_estimation.
Every programmer knows to pad estimates, but I don’t see how this helps. For example, at my last job, everything was complex enough that every task would fall into the “Ouch… that’s a HUGE task” slot (actual estimate: 2-20 days). And managers would never be happy knowing that the 3 features they wanted me to do for the next release would take between 6 and 60 work days (1 week and 3 months), but also never be willing to schedule any time for improving the codebase.
I have the tendency to underestimate. Having learned my tendency, nowadays I always multiply the initial estimate by a personal multiplier. For a somewhat smaller task I’d multiply it by 2 where as if it is bigger task the multiplier gets upgraded to 3-4.