Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I don't want to make life hard for management. I really don't. They're nice enough guys, but every time I am assigned a new project or task and get asked "how long do you think it will take to do this" I end up sputtering off ridiculous timeframes; "between a day and three weeks".

I would like to believe that it's not entirely my fault: I am the company's sole programmer, I am relatively new to proper development (Was it only six months ago that I wrote my first unit test? sigh...), and I am working with a code base that at times is downright absurd.

So I would like some advice. Obviously, experience is the biggest thing I lack but anything that would make me better would be greatly appreciated. I am looking for reading material, methodologies, maybe even actual tools. Any way that I can give my boss more accurate information without having to sit down and design the darn thing first is appreciated.

Ok magic stackoverflow genie, what have you got for me?


@Vaibhav and others suggesting I take time to research and sketch out the system

I agree with you in principle, but how do you balance that with real-world constraints? When you're a one man show or even a part of a small team "I will need 2 days to build an estimate" is a real deterrent when you can fight 4 fires in the time it takes to get a simple estimate.

share|improve this question

migrated from Jan 24 '11 at 14:21

This question came from our site for professional and enthusiast programmers.

marked as duplicate by gnat, Yusubov, MichaelT, Kilian Foth, Martijn Pieters May 22 '13 at 7:00

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

No, but my boss thinks so.. Actually, I usually have to give an estimate there, right on the spot. – borisCallens Dec 10 '08 at 12:11
+1 for boris. My boss also demands estimates on the spot. Even if I ask if I could get back to him in a few minutes, he always seems to squeeze some sort of bull**** estimate out of me right there, as if giving me a few minutes is too much time to spend on an estimate. – James Jones Aug 17 '09 at 15:08
if It makes you feel any better its hard to estimate any development task that is non trivial. You can run into issues and if you have to deal with other development groups forget about it. Guess then reestimate and keep you management informed is about all you can do. – rerun Feb 16 '10 at 21:10
I'd typically do some research up front to see what I'm getting into. Once I have a general feel for whats involved, I give my estimate in a [best case] - [worst case] amount of time, there is usually a pretty large span. You don't want to give an estimate on something you know nothing about. Do some research first. If you are put on the spot, ask for some time to do research and see what that task will take and then give a response later. – aepheus Feb 16 '10 at 21:21
Six to eight weeks. – Aaronaught Feb 18 '10 at 15:24

36 Answers 36

As a developer who became a project manager I can tell you that this is not easy. The key point is to break the task down into smaller and smaller chunks, estimate each one then add your estimates together. Obviously this may take some time so speak to your PM about how long you have to produce the estimate. Also any good PM will know that an estimate is just that, so keep them informed with your progress, remember ultimately you are all part of the same team.

Hope that helps,


share|improve this answer

One of the classic techniques in project management is to take 3-point estimates. Basically ask yourself how long is it going to take (or how much effort is required) to finish this task? What are your optimistic, most likely and worst-case-scenario guesses? From what you say you will probably come up very large gaps in your estimates, which indicates risk.

What you need to do is to try and reduce that risk as much as possible. Here are a few things you can do (as you probably already thought of):

  • Read about the subject
  • Create a spike
  • Ask others who has experience (don't be wrongly influenced though!)
  • Make sure your project manager knows about this!

After all this estimate again to see if there are any improvements ;-)

share|improve this answer

The important thing is not giving an estimate that "sounds" OK for your Boss because he's expecting something, just really estimate what you think. If he questions your estimate, just say that you'll keep him updated from time to time and remember him that you've never work with the technology.

Also, I always make two estimates, the pessimistic and optimistic scenario. I ADD 10 to 20% at the total for tests and debugging (normally, nobody will ask you to remove the debugging time).

share|improve this answer

Estimate on the estimate.

In many cases coming up with the estimate for a project represents a lot of the work involved in the project. If you can establish the trust of your clients, you can charge a day-rate to develop an estimate. This has a number of benefits for you and for them.

  1. The estimate will be more accurate
  2. You'll know what you're about to do and they'll know what help you need
  3. You can walk away without hard feelings if the project looks too expensive

The standard timeframe for planning on construction projects is 10% of the total timeline for the project. No reason to throw out hundreds of years' learning for a few transistors.

EDIT : For smaller projects this phase is usually where the needs assessment and feasibility study get done for free by a hungry developer .... most of us have been there ....

share|improve this answer

Based on your question it is obvious your management has as little experience with managing software systems as you admitted to yourself. What's needed is retraining management, but that will take time. My advice to you is this:

  • If management demands an answer on the spot, tell them it will take X amount of time to give you a more firm estimate, but my soft estimate is .... Give a wide range, and if they ask for a narrower range inform them that you need time to do the proper estimate. NOTE: always provide at least a day so that you can come up with the firm estimate.
  • Always state your assumptions with your estimates. I.e. assuming I have no interruptions, I should be able to do this feature in X amount of time.
  • Give your firm estimate to the manager after you have enough time--even if they didn't ask for it. They'll start to get the picture that the firm estimates are more valuable.
  • Keep track of your estimate and the actual time you spent. This will help you know if you need to adjust your estimation process a bit.

As always, an estimate is a projection, not a hard and fast rule. What this means is that when it looks like you are not going to meet your projection, you need to let someone know. That will let your management chain make adjustments before they commit to the wrong people an unrealistic date.

share|improve this answer

No matter how good you think you or your team is, always overestimate.

share|improve this answer

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