How am I supposed to know how many days something will take? [closed]

Answer 1

Time estimation is hard.

But the times when I've done this well all have a couple things in common:

1.) I received very good and complete requirements for the project. This is important and you should ask the tough questions to make sure that the requirements really are as complete as possible.

2.) I broke the project down into sections, wrote each section on a white board, and then estimated the time for completion for each section individually. I had the rest of my team contribute as I do this so I don't forget anything. This seems so simple, but it works so well. I think it allows you to be more realistic by reducing the possibility of overlooking a part of the project that may be time consuming. If you can write down and plan out the project at a granular level like this it'll help immensely.

During this whole time estimation process you may even gain a better understanding of the project and what needs to be done. That can prevent mistakes, writing & re-writing code, etc. And that's good for everybody.

Answer 2

Murphy's Law of Time Management:

To figure out how long something will take, start with how long it should take.

Then, multiply this by 2.

Then, move to the next higher unit of time.

Thus, if a project should take one day, it probably will take two weeks.

Answer 3

• Being asked to quote in days is ridiculous, the best you can do is estimate.
• Try at all costs to avoid being coerced into giving an outright guess, you will almost certainly be wrong. Buying some time to make a better estimate is always a better idea.
• If you are dealing with changing or interfacing with some code you have no previous experience with, then try and give an estimate of how long it will take to work out how to do what you need to, then get back to them when you know more precisely what you need to do with an estimate for how long.
• The same goes for doing things you have never done before, you will likely deliver sooner if you do some research into how similar problems have been solved by others.
• Break your tasks in to smaller chunks (as small as possible) to estimate more accurately. That way you can say something like "I think A,B and C will take about 6 days altogether but D is soemthing I will have to look". It sounds a lot better than "I have no idea" or "as long as it takes".
• You cannot estimate the time it will to take to find a bug. You maay be able to estimate how long it will take to fix it. A tough bug can easily take 2-3 days to track down and fix. Bugs in code you already delivered will eat into your time on subsequent developments.
• Always let them know when you hit a problem that will make your deadline slip well before your deadline. That way your boss is forewarned when talking to his boss/client.
• If you over estimate and are lucky enough to have some extra time, either test it some more or use the time to develop something else that will be useful to your productivity as a developer.
• If you are continually bullied into agreeing to arbitary deadlines, constantly harrassed or feel your explanations are recieved as though they were outright lies then quietly start looking for another job at a firm that understands software project management before your health inevitably suffers.

Answer 4

Go with your hunch and then add 50% time. You'll meet the deadlines, won't stress yourself, your boss will see quality code over fast code and you'll probably be faster than expected once in a while. Everybody wins :)

Answer 5

Past experience and historical data often work best for providing estimates. If you've dealt with similar code/issues before use the historical data to predict future tasks. Of course if you're dealing with something new or entirely unknown, then it's harder to provide accurate estimates. Of course they are 'estimates' which is an educated guess as to when things will be done.

Answer 6

Here's a link to a great book by Steve Mcconnell (aka Mr Code Complete): http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351/ref=ntt_at_ep_dpt_3 - Software Estimation Demystified

The basic steps are:

• break down the pieces to understandable/workable chunks (look into workbreakdown structures)
• if there's an item that you need more info on, note it and make sure you inform your manager ASAP
• the piece's that you have should include items that are like others you've done before - which should make it easy to provide an est. on those, items you have some 'rough' idea about how long it SHOULD take (add a % over your gut reaction time based on your comfort level - say somewhere between 10% and 30%) and those items you just have to take a wild guess at (add a % range to those, which could be anywhere from 30% to 500%)
• put you list of deliverables together in a spreadsheet, name each item, comfort level of completing (high to low), your time est. - which could be a range (min. 1 day to max 5 days) and any notes that could include questions and assumptions.
• present it to your manager and discuss

A doc to talk to that includes the items needed to be completed, questions, assumptions and a range of possible delivery dates speaks a lot for your level of programming maturity - compared to someone who throws out a # of days/weeks (or just a snide remark) and never comes close. If your manager doesn't appreciate that - find a new manager.