2. Estimate how long you think each will take, knowing it always takes longer than you think.

3. Realize it always takes longer than you think, and revise your list.

4. Double everything.

5. Round up.

6. Add it all up, walk to towards your bosses office and/or call the client.

7. In a last second panic realization that it always takes longer than you think, double it again.

In all seriousness, you will get better over time, namely after you do this many times. The only "secret" to the process is write down a detailed list of the things that must get done. Alot of people tend to clump up alot of the endgame details as "polishing" and that results in the 90/10 rule taking full effect (that the last 10% of the work takes 90% of the time) because things like UI testing, inserting the logo, doing the install script, etc, etc, take forever and a day.

9. Rationalize cutting it down.

10. Kick yourself as you struggle to meet impossible deadlines.

It sometimes helps to keep doubling it until it seems funny that it could take so long, and then step back once. ie, "Writing a parser will take a week. Two weeks. Four weeks... weeeeell, probably not four weeks - two weeks it is."

I also like to front-load things that I'm uncertain about, as playing catch-up near your deadline is easier when you have (hopefully over-estimated) well known tasks remaining.

I try to take into account how accurate my estimates will be: if a sub-task is something I've done alot, I stick with my estimate; if it's something where I think there's a risk of it going wrong I add more time (keeping a note of the estimate and the risk time separately - it makes project managers think you know what you're doing!). I then add them all up, divide by 0.7 (roughly how efficiently I convert booked hours into directly worked hours - the rest is email and meetings etc.). Also, any task where you have to write code that works with someone else's code, I double the estimate.

1. Do ENOUGH design and requirement gathering up front. Talk to stakeholders and users. Play around with any unfamiliar technology that you're required to use. In short, get your bearings before you start estimating.

2. Extract tasks that must be done. Each task should take less than a day or two to complete - larger tasks than this are often "lumps" of work which are harder to estimate accurately. Divide as needed. Don't forget testing, bugfixing, "polish" and all that jazz!

3. Estimate each task in IDEAL hours. Ie. "how many hours would this take if I could focus 100%, no interruptions, closed office?" Another approach is to estimate entirely using relative units - go google the "Poker Planning Game".

4. Add up total ideal hours. Then multiply by a risk factor. (My absolute minimum is 20% - that's if I have a complete lock on both the technology, the requirements and ALL other significant project factors.)

5. Figure out how many IDEAL hours you actually get done each week. How much effective time do you have left when you subtract meetings, interruptions, lunch, motivation lapses, etc etc? Divide the hour number from step 4 by these actual hours accomplished each week.

6. Now you know roughly how many weeks the project will take. Then take into consideration miscelleaneous external constraints. Will Joe Developer be there week one or is he tied up? Will Sue Tester go for a three week holiday to Hawaii at some point? Tweak the schedule further based on such known specific "X factors".

7. By this point you have a rough idea of when you will be done... in an ideal world. :)

Note: This is what I do for small projects or single iterations/increments in larger projects, ie 1-3 months for a few developers. Larger processes / project scopes = different techniques. Go google Agile/Scrum/other modern development methodologies. :)

http://www.overcomingbias.com/2007/09/planning-fallac.html

It also helps if your development cycles are fairly short (i.e. 1-2 weeks and no longer). I have found that it is much easier to estimate how long it will take if the amount of work you are estimating is smaller.

Keeping your development cycles short also has the beneficial side effect of reducing the shock factor when you have to double it.

Unless you're doing fairly repetitive work (cranking out brochure websites for clients, for instance), you shouldn't be doing any "roughly similar" projects! Each thing you do should be brand new—if it wasn't, you'd just reuse the code you already have.

That is the perennial dilemma in software estimation. You don't know how big it is until you're halfway done building it.

I'm not proposing a solution to this problem, just pointing out that this IS a problem, and probably not one that can be solved in a one-line bit of advice. Saying "cut it up into pieces" or "estimate similar past projects" is like telling a nervous guy to "just be himself" on a first date.

I've worked on projects where we needed to do details work breakdown structures: http://en.wikipedia.org/wiki/Work_breakdown_structure

And I've been in environments where I had to wing it with ever changing requirements where everything was all over the map.

Somewhere in the middle is the happy ground.

For perspective, I recommend reading the following book:

Software Estimation: Demystifying the Black Art by Steve McConnel (http://www.stevemcconnell.com/est.htm)

[Edit] Estimation is an iterative process both within a project (even if you are stuck in a god-awful waterfall) and with consecutive projects. You self train your estimation skills for doing similar work. Its when you hit something new that you don't have the past performance to draw upon that you really have to rely on your instincts. As a bottom line, I'm much less wrong when I go with my gut instincts than when I analyze and estimate ad nauseum.

http://www.joelonsoftware.com/articles/fog0000000245.html

http://www.joelonsoftware.com/items/2007/10/26.html

* For a known task, developer are usually too optmistic by about 30%

* At the very beginning of a project, your estimation can be off by as much as 400%, by the time you have the UI done (at least in wireframe), your estimation can be off by around 25%.

Also, I suggest reading the "Three points estimation" part of this article : http://www.projects.ed.ac.uk/methodologies/Full_Software_Pro...

It's usually for "big" project, but the Three points estimation technique can be used even if you are by yourself. Also, it's more scientific than just "doubling" your number (check Standard Deviation on wikipedia if you want to understand how it work).

Finally, with this technique, it's easy to spot tasks which have alot of uncertainty.

Divide the project into smaller pices. If your estimate for a piece is more than a day, it is still too big.

To make sure you know what is involved in implementing a piece by always including how to perform a function-test of the piece. This is powerful for those pie-in-the sky estimates that go "Ohh, that cant be so difficult..."

When it comes to fixing small bugs, verifying bugfixes, or other repetitive work, collect historic and use the average time, and multiply it with the number of things to do.

With this approach, I typically manage to time-estimate well enough for a 3 week sprint.

I have also began using a burn-down chart where I input number of hours worked on the project each day, so in the chart i can see how my remaining time burns down, and on top of that how many hours i did work each day. Making the remaining time bars black and the hours-spent fire-yellow, it is a really pretty "burn down" chart. If the fire is as big as the estimate decrease, im spot on with my estimates.

People say they double their estimates, but I find it no longer necessary, I usually hit the time 1 hour +/-.

http://inter-sections.net/2007/11/10/easy-estimates

In my most recent 1.0 release with was done with Scrum and Sprints, what we observed happening was that overallocated time (tasks that did not need 6 days but took 2 days) was reallocated to tasks that needed much more time (10 days instead of 5 days). We were fortunate to usually meet our backlog for the Sprint (sometimes, more complicated tasks carried over) - but in practice, it seems that we had a fixed amount of time and the time estimates merely did a initial slice-up (which was not accurate). We hit the (pushed by 3 months) release deadline - however there was a fair amount of overtime.

So, if I had a lesson - the moral of the story is - time estimates are nice but being all-in and committed to getting a product out the door is more important.

One of the key elements of PSP is to record what you do each day in a little diary. One of the biggest ways you can improve your estimation skills is:

1 - make estimates

2 - keep track of how close those estimates came to reality

3 - compare what you did right/wrong so you can do less of the wrong and more of the right.

http://en.wikipedia.org/wiki/Personal_Software_Process

http://www.amazon.com/Discipline-Software-Engineering-SEI/dp...

http://www.sysmod.com/psp.htm

Even doubling your estimates is unlikely to have any real reflection on reality.

One standard methodology is called three-point estimation: http://en.wikipedia.org/wiki/Three-point_estimation

How far do you want to go though? You could look up COCOMO-II, I saw someone mention function-point analysis, then you could do monte carlo simulation...

The best way is to compare the task to previous similar tasks, but the trick is making sure that tasks are really similar enough to make an accurate comparison.

http://www.microsoft.com/learning/en/us/books/2425.aspx

I would even call this book a survival guide.

Surely such an overly simple estimate is going to be wrong? Well yes, but reality is complex and no calculation is going to capture it correctly.

If you find 1 week per page is too inaccurate you can update your future estimates based on past performance.

Agile folks have the concept of 'velocity' which helps them to predict delivery dates based on accuracy of previous estimates.

2) triple it