I always start the day thinking "I'll easily get this done by the end of the day" and set what looks like a realistic target.

So why do I never hit it? The task always ends up taking 3x longer due to unforeseen bugs, last minute changes etc.

Is it just me? I don't seem to be getting any better predicting what can be done in a day.

  • 8
    It's not just you. See Hofstadter's law. Commented Nov 2, 2010 at 16:45
  • 19
    Because you're wasting your time asking questions on P.SE, instead of doing your work :) :)
    – Jas
    Commented Nov 2, 2010 at 16:50
  • 2
    Next time you estimate a task, multiply the result by 3, and you are safe ;)
    – user2567
    Commented Nov 2, 2010 at 18:20
  • 3
    I do not plan to get done anything, and I always win. I size all my bugs as infinity, so my velocity is always undefined.
    – Job
    Commented Dec 14, 2010 at 18:20
  • 1
    My old boss used to say my time quotes were in cat years. I think he just moved every quote up by one order of magnitude. Hours -> Days; Days -> Weeks; Weeks -> Months; Months -> Refund Client.
    – Orbling
    Commented Dec 14, 2010 at 22:10

11 Answers 11


Because you were never taught how to plan.

Planning is a skill, just like coding or writing. But somehow it is left out of nearly every curriculum.

It needs to be learned and practiced, and your estimates of your own capabilities need to be continuously updated. This is why work practices like Agile emphasize measuring your past actual work and comparing it to your estimates, so that you can improve your planning abilities.

As others have said, you need to account not only for the task, but for all its predecessors, attendant tasks (e.g., learning how to do X), and you need to be cognizant of your own internal mental biases that will prevent you from correctly accounting for the way you actually do work.

Train on it, and who knows, you might get better.

  • 8
    Aside from just not planning for all the little time eaters in a day making planning hard, planning is also a skill that's not fun to learn. When you make a coding error, you get a bug and you fix it and you learn a lesson. When you get a planning error, YOU FAILED!!! Slipping on deadlines makes you feel bad and it makes you feel a failure, so many people just don't plan. To counter this, I started keeping very detailed, itemized todo lists, but I always give myself stupid amounts of extra time. Then I feel really accomplished because I'm always under budget on time! Commented Nov 2, 2010 at 17:07
  • @Codex, great point. There are ways to make "planning failures" into something you can 'code a fix' against. Every planning failure is an opportunity to learn. Look into a technique like Root Cause Analysis to help understand the context of the failure, so you can plan better next time and introduce specific countermeasures that will head off the failure in the future. Commented Nov 2, 2010 at 17:59
  • 1
    Not only is it not fun to learn, it often feels like a waste of time. I call it "metawork" - spending time analyzing or organizing your body of work. When there's tons to do, metawork can feel like you're building yourself an insulated cave underneath the avalanche instead of trying to dig yourself out, but really what you're doing is sharpening your tools in preparation for the job ahead.
    – nlawalker
    Commented Dec 14, 2010 at 18:28
  • As of this writing, there are 11 people who have upvoted this answer. Which means that there are 11 people that are under the delusion that there actually is such a thing as a plan that will correctly estimate the time required. Commented Dec 14, 2010 at 21:19
  • @nlawalker: Not fun to learn? If I've not learnt something new in a day, hell in every hour of the waking day, I consider the day a failure.
    – Orbling
    Commented Dec 14, 2010 at 22:13

Hard to believe that nobody has mentioned Hofstadter's law yet.

I think the real answer is that your planning always assumes a best-case scenario, as if everything worked immediately an no interruption ever occured. In real life, you start coding, then the telefone rings, you are distracted for 5 minutest, spend another 15 minutes on stackoverflow or programmers.stackexchange to calm down and refocus, do some coding, run into an unexpected behaviour of some API, do some googling, spend 2 hourse to test the possible solutions etc.

In other word: "best-case" only happens in your dreams.

  • 1
    See @Peter Broughton's comment (5 hours before your answer!).
    – ChrisF
    Commented Nov 3, 2010 at 9:11
  • Yeah, you are right, ChrisF. Must have missed that one.
    – user281377
    Commented Nov 3, 2010 at 9:30
  • +1. This is essentially why I go by the "make a reasonable estimate, then double it" rule. And even then it often takes longer. One of my lecturers at uni used to say "triple it". So I guess I'm doing okay. :) Commented Dec 15, 2010 at 5:38

Every programmer, once in a great while, has a perfect day. You wake up 5 minutes before your alarm goes off feeling great. Breakfast is made and on the counter, along with fresh coffee, so you can grab something and head out the door. During your commute you hit every green light, and traffic seems to be especially light. Contemplating the day ahead of you, you are able to fully understand the design and consequences of the task ahead of you, which has been well planned with firm requirements.

You get to work and you find that you have no important emails, no voicemails waiting, and your co-workers are either out or in meetings that you don't have to attend. You fire up your editor and are immediately in the zone, you can feel the structure of the code and see your data structures and algorithms fitting into place within a beautiful and cohesive whole. Thoughts flow through your hands to the keyboard, entering perfectly formed code that is elegant, maintainable, and with not a bug to be found.

During the day you work with no interruptions, the office is quiet and you are so focused that you're never tempted to spend any time catching up on the news, blogs, etc. When you compile and run your tests, you find that everything works without a hitch, of course you knew it would, and at the end of the day you commit with no conflicts. Glancing at the clock on your way out you realize you put in 12 hours and it felt like a brief 20 minute coding session.

That day, that perfect day, is what we assume we'll have every time we have to estimate anything.


Don't forget about meetings, people interrupting you, etc. Unforseen bugs are difficult to predict, but over time you should be able to get an idea of how many bugs you uncover within a certain time frame. When estimating how long something will take, you have to consider the context. I.e. "Assuming I don't get interrupted or uncover bugs I should be able to do something in X amount of time"

As a little exercise for yourself, consider doing the following:

  • At the beginning of the day, write down what your goal is and the time estimate for it.
  • At every interruption (meeting, coworker talking, etc.), jot down the approximate length of time
  • Every time you find a new bug, jot it down as an unplanned task along with approximately how long it took to develop it.

You'll find some patterns start to emerge, and can plan accordingly for those. Any time you tell your manager an estimated time of completion, just caveat it with the assumption in the first paragraph. You might be surprised how accurate your estimate was when you remove the time spent on interruptions and bugs.

When you are working to a bug list or feature list, you are probably already doing the first and third bullet point. That little exercise will tell you where all your time is going, and you might be surprised at the answer.

  • +1 If I jotted down every interruption I received, apart from needing to order stationery more often, I would lose a sizeable part of the day to notation.
    – Orbling
    Commented Dec 14, 2010 at 22:14

You may want to expand you timeframe of predictability. Can you determine what you can get done in a week? If every task is taking three times longer than you thought, it sounds like you're consistent enough to be predictable. You just need to adjust by 3x ;)

  • +1 Consistently wrong is still consistent! Result.
    – Orbling
    Commented Dec 14, 2010 at 22:15

cuz you simply ignored the fact that unforeseen bugs may occur.

Do some statistics on the average time you spent on the bugs, and take those time into account when you make your plan.


Because you aren't planning correctly. Ouch.

I bet if you keep a running total of how much you slip by (on paper even), then adjust your estimates up by that %, you'll be able to plan correctly.

FWIW, software is notoriously hard to estimate. McConnell (of Code Complete fame) has a book out on it even.


Something I often find myself doing is getting distracted by random stuff that is unrelated to what I'm doing. A todo list can help with that; when you think of something, write it down and do it after you finish what's in front of you.


Because I spend too much time on Stack Overflow.


Urgent/Important Matrix may be worth considering to see where does your day go. Is it on urgent but not important stuff like unprepared meetings and interruptions? Is it on urgent and important stuff you didn't know at the start of the day? Just an exercise to consider where does your time go.

I'd tend to think most interesting things are important or else why are they interesting? Just a thought.

  • 1
    My problem with that technique has always been it's invisible "third dimension": how INTERESTING something is. Unfortunately, for me, interestingness trumps urgency and importance every time.
    – timday
    Commented Dec 14, 2010 at 21:03

That's a good question and one that I'm constantly pondering. I tend to think that

  • it's very easy to misjudge the amount of work feature X will take.
  • I never plan for bugs or trips to the kettle.
  • either you get a lot done with little code or nothing done will lots and there seems to be no in between.
  • sometimes you lose your 'zone', sometimes things need thinking through.

Not the answer you're looking for? Browse other questions tagged or ask your own question.