.NET Zone is brought to you in partnership with:

I'm a software developer working as a senior consultant at Kentor in Stockholm, Sweden. My core competence is as a technical specialist within development and system architecture. In my heart I am, and probably will remain, a programmer. I still think programming is tremendously fun, more than 20 years after I first tried it. That's why my blog is named Passion for Coding.  Anders is a DZone MVB and is not an employee of DZone and has posted 85 posts at DZone. You can read more from them at their website. View Full User Profile

Programmer Time Translation Cheatsheet -or- Why Programmers Are Bad at Estimating Times

  • submit to reddit

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.

Published at DZone with permission of Anders Abel, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Barry Smith replied on Thu, 2012/08/02 - 4:48am

I would add though that, as a developer, I can often make quite accurate estimates, I just can't justify them. My estimates are often of the form - I can think of tasks that will take about a day, I know other stuff will crop up that will take another day or two, but until I get started I won't know what that stuff is. So, I can't include that in the estimate because I will be asked to justify it and I can't yet. So, I'll say a day because that's what I can account for and I'll overrun later. I'll just have to live with looking incompetent after the fact than right now. When it's actually your fault, project manager, for not being willing to accept I know what I'm talking about when I said 3 days in the first place and you forced me down to 1 day.

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: 

Philip Metzger observed 15 years ago that developers were fairly good at estimating but were poor at defending their estimates (Managing a Programming Project, 2d Ed., 1981). I haven't seen any evidence that developers have gotten any better at defending their estimates in recent years. Several underlying factors come to mind. 

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. 


Philip Metzger observed 15 years ago that developers were fairly good at estimating but were poor at defending their estimates (Managing a Programming Project, 2d Ed., 1981). I haven't seen any evidence that developers have gotten any better at defending their estimates in recent years. Several underlying factors come to mind. 

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

Great Post;
Inspired me to share a bit of my own view on how to tackle such estimates-

Pan Li replied on Mon, 2012/09/03 - 1:03am

Hi, can we translate this article to Chinese on our website http://www.ituring.com.cn ? Ituring focus on IT and science books and information, and we use markdown on this website. Of course, this article will open to all visitors freely, and there will be a link back.

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:

 At the individual level, surveys of estimated vs. actual schedules have found that developers' estimates tend to have an optimism factor of 20 to 30 percent (van Genuchten 1991). 

 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


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 ? :-\


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. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.