Programmer Time Translation Table

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.


  1. 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.

  2. 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.

  3. 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?

    1. 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.

    2. Hofstadter’s law was the first thing which sprang to my mind, however, it was more as confirmation of the usefulness of this post rather than evidence of estimates not being necessary.

      The fact is that Hofstadter’s law is a) anecdotal, and b) tongue-in-cheek. James is right. Estimates have a huge importance both to reassure the customer, and to enable the vendor to manage their workload. Would you say that deadlines, planning and scheduling also don’t have a place in business? All these depend on estimating time. The point this table and Hofstadter’s law make is that a) estimates need to be made with care. b) expectations need to be managed so that when something goes wrong, both the customer and vendor are able to modify their plans and emotions accordingly.

      Obviously Hofstadter’s “law” isn’t really a law. It is possible to overestimate, and as a result complete the work in less time than you have told the client. In my experience, more often than not clients will love you for it.

  4. 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.

    1. 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?

  5. 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

    1. 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.

  6. 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.

  7. 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!

  8. 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”.

  9. 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!

  10. 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.

    1. I like the four hour chunk idea; it breaks up nicely into two to three periods per day separated by lunch/dinner breaks/meetings. It’s similar to how we organized & planned at the last place I worked.

  11. 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.

    1. 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.

      1. “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.

  12. 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.

  13. 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.

  14. 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.

  15. 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.

  16. 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.

    1. Your list gave a few good laughs as well. I have to admit that some of them were spot on to things I’ve said myself in the past…

  17. Few organizations use there own tactics or logic to calculate the estimation hours. this is based on the experience of developer, lines of code, number of program involved etc…

  18. I loved the reference to the 3.14 conversion rule – right at the very beginning. Definitely got my attention – to read the rest of the article.

    We follow extreme programming in our teams – at least I *think* we do :). So I believe we’ve gotten to a point where accurate estimates have a high level of importance in the minds of everyone on the team. Here’s how we do things – at a high level:

    In our team, we use MMF’s (or more simply, just features), stories and “engineering” tasks – as the 3 “layers”.

    – The MMF’s are usually no bigger than a week of effort (estimated by everyone on the team)
    – A story is usually a 1.5 day’s effort (created and estimated primarily usually by our business analysts – we’re trying to make this 1 day though)
    – An engineering task is usually about 4 hours (of course, estimated by engineers. At this point, the BA get feedback on their estimation – and breaks stories down further – or glues some together – if there’s a significant amount of difference)

    We used to rely on relative size estimation for MMF’s and Stories (as suggested by Mike Cohn) – but over the last 6 months or so, we’ve moved to breaking down things to the same level of granularity (at that particular level, of course)

    One thing we’re trying to improve on is the right granularity at which to break down tasks into – staying on the right side of the “diminishing returns” curve is hard.

    We don’t have a specific time allotted for estimation – at least for the engineers. The time to be invested in estimation – is considered as unplanned time when stacking up stories for the upcoming iteration.

    Finally, to keep our estimates accurate, we split stories into two groups – “definitely” and “maybe” – before we provide a commitment to our customers.

    But the thing we don’t do (at least enough of, yet) – is consistently measuring how well we’re doing as regards our estimates. That is the main takeaway, I got from your article.

    Thanks so much for writing this. I totally enjoyed it :).

  19. Oh my God. I recognize myself soooooo much in this! It is true. Sometimes I am puzzled on how long everything takes! And then I wonder how we ever advanced in the C / C++ era…. I guess it is because we didn’t write automated tests which do take a LOT of time but save a lot of bug-fixing time AND guarantee stable code. I always hated test cases. But now I can’t live without anymore…

  20. For RAD, AGILE and such methodologies, move decimal place up an order of magnitude to account for “but what I really wanted was” time.

  21. Um, you guys know that programmers created this paradigm so that we would have tons of free time to work on our own projects, and generally slack off, right?

  22. What about when you are dealing with a previews developer code and someone ask you to change an image.

    You immediately say: No problem, it will take a minute. It’s all about changing the image name and uploading the image to the server.

    Then you find out that the image is a parameter name on a template that you can’t find because there are several templates and some even have similar names and the image name is a reference in the database allocated in a table somewhere in the database.

    And to make it more dramatic, the development environment is protected by a constant located in the database with a salted password that nobody told you about.

    Often, you can find nasty developers who think that security is to make everything dark and unavailable.

    Estimating code troubleshooting, I think it depends more on the developer experience than anything else. And often, it’s impossible to predict because you don’t know what you are going to find.

  23. Whatever you can estimate you can automize ;-)
    And as always: it depends on the size, complexity, phase of the project and people maturity of assigned staff.
    If you do something the first time: don’t estimate! Give youself a timeslot and watch your progress. Not satisfied ? Give it to a more mature person, freelancer, rething the requirements of let it be!

  24. Pingback: Hofstadter’s Law

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.