Programmer Time Translation Cheatsheet -or- Why Programmers Are Bad at Estimating Times
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Barry Smith replied on Thu, 2012/08/02 - 4:48am
Endre Varga replied on Thu, 2012/08/02 - 7:22am
When I did time estimates for myself, I strictly used the following "units":
1h, 2h, 4h and 8h
Anything longer would be split into subtasks. There were no shorter estimates than 1h. I usually added 10-15% grace time to the sum. I used this for several months, and I usually ended up overestimating slightly the amount of work, so it worked quite well. I totally agree with your sheet.
Karol Lalol replied on Thu, 2012/08/02 - 8:43am
I don't agree. Barry is right. Steve McConnell is supporting this theory:
So try to read some his books, and recommend it to your senior PM so he is able to get right information from his programmers ;-)
Hafizan Aziz replied on Thu, 2012/08/02 - 9:37am
You're are bad manager just given order and have no strengh of managing people.. it's not abour hours but it's about you give the programmer nessary equipment and tools.. If the tools it's free and no license. wondering around it's normal.. It's your job to ease programmer not to bash them.
Anil Kumar replied on Thu, 2012/08/02 - 11:23pm
I don't agree. Barry is right.
When ever i giving the estimates Anything longer would split into subtasks and give my estimates with 5 to 10 % grace time(Some PM's are allows Grace Time .:().
I fell if the buinsess requirement is finalized(Work scope) developer can give estimates accuratly with +/- 5 to 10 % of deviation.
Some time developer's not know the impact until he go inside the task as because of the lot of factors
Documenation might not be sufficient enough
Changes in Work scope in middle of the developement
He doen't much familar with the module which he going to work on etc...
Mica Lucia replied on Fri, 2012/08/03 - 10:00am
Wow, registration for this site is so long but I wanted to share my oppinion as a PM. I am not a senior PM, I do not have diplomas but I have written code. I have been QA and BA before PM.
I agree with the devs that commented above. They are 100% right.Time made me trust the devs oppinion and they trust me because I listen to their concerns and have their backs in case anything goes South. I understand what drives their logic when they estimate and I do not expect them to take into account the neccessary time to open a computer. LOL. Seriouslly?
When you ask them for estimates is all about asking the right questions. A PM that just drops a "How long to get this done?" and then leaves is a bad PM in my books. Devs have to get familiar with the code to give you an accurate estimate. Not all the time, but the majority of time.
I listen to their concerns, I notice when they are not sure about a particular task and I know how to make them think outloud.
got to know them and understand what drives their logic when they estimate.
Kenny De Metter replied on Mon, 2012/08/06 - 11:56pm
in response to:
Barry Smith
I typically try to solve that be estimating a time to investigate it, just enough to make an estimation.This is useally easier , because you already know what you need to do there.
So, if they come with a fuzzy requirement, i'll may tell them : "I will to look into this for 1 day, to make a better estimation"
After all, estimating also requires some time.
If you are interested, "The Clean Coder" , by Robert C. Martin has a good chapter on estimating.
He explains that an estimation is exactly that : an estimate . It's never accurate, because you can't know the future.
He suggests describing estimation as probability :"it will likely by finished by tommorow (50 %) , but it's quite possible it will take 3 days if some problems pop up ( 40 % ) . If it goes really bad , it might take 1 week ( 10 % )"
.
Or Weis replied on Thu, 2012/08/09 - 7:04am
Inspired me to share a bit of my own view on how to tackle such estimates-
http://shulaventures.wordpress.com/2012/08/09/time-estimates-the-unknown/
Pan Li replied on Mon, 2012/09/03 - 1:03am
Graham Lee replied on Thu, 2012/09/06 - 12:22pm
in response to:
Karol Lalol
Steve McConnell also says (CC2E, section 28.3) that developers are overoptimistic at estimating:
So apparently he can have it both ways.
Vic Aston replied on Thu, 2013/01/10 - 9:58am
in response to:
Barry Smith
Barry, Think you nailed this one! All to often PMs force there timeline performance requirements on ours. Unfortunately, we as developers usually give the in-accurate estimate to start with. When estimating how long fixing and/or creating code, a developer really needs to understand the overhead tasks involved before stating a fixed or variable amount of time to the non-developer type.
Claudio Silva replied on Wed, 2013/01/09 - 1:19pm
Hi!
Very interesting thread!
In my opinion, before estimate you have to analyse and specify what to do. If you don´t know how to do what you have to do, how can you estimate its duration ? :-\
So:
1. first you have to take a look at code related to the task - It´s inspection.
2. If you find some part that use a module or technology that you never coded for or if you have to use some feature of the framework/language, you have to write a spike (a little code whose goal is learning, can be the worst an quickest code you can do because it´ll not be considered in the final implementation).
3. Once you know minimally the code you have to change, learned how to use modules/features/technologies envolved in your task and you have a solution, you can estimate.
4. Im my team, tasks that take more than 1 day must be breaked into small pieces to help the dev reduce uncertainty.
It works for us: a small team of 4 devs and 1 leader.
Michael Bogomolsky replied on Wed, 2013/01/09 - 3:27pm
I personally don't think time estimates work at all. You may get lucky sometimes if work that required to do is very similiar to one you've done already. But for brand new development with potential introduction of new technologies or framework, customer changing requirements, forget about it. This is why agile project management approch suggests relative estimations, they ending up to be much more accurate more you use them. And it removes need of asking developers how long will it take, I think it's just a bad question to ask.
Ask to size of the work (relatively), learn with time how long on average takes to build task of this size.