views:

161

answers:

8

Possible Duplicate:
How to estimate the length of a programming task

This might be out of scope for this website. If it is, let me know and I'll remove the question.

After 15 years in the industry, I still suck at answering the question "How long do you think X will take?" For scheduling purposes, we always have to give an estimate of how long different sub-tasks in a project will take. What's the best way to get better at estimating how long it will take to do something?

Some people are really good at this. Are there any books, techniques or whatever that people use to get better at this?

+1  A: 

This question is probably a good place to start: http://stackoverflow.com/questions/14279/how-to-estimate-the-length-of-a-programming-task

David Johnstone
A: 

I think you know yourself better than anyone. After 15 years you should know how fast you can do things? I definately understand your conundrum however, I often say 2 months for a deadline and fine myself not even closing to the first phase...

Laykes
My problem is, none of my projects ever remotely look similar to when I was doing a couple years ago. I'm a hardware guy, and 15 years ago, I was doing board design and FPGA design by schematic capture. Then it was FPGA's with VHDL and Verilog. Then it was ASIC design. Now, some of the ASIC tools are starting to incorporate object-oriented programming. All the while, gate counts are doubling ever couple years. My estimation skills are a victim of Moore's law. People do it though, so there's got to be a more systemic way of doing things.
SDGator
+1  A: 

Lots of people have problems with this and it usually boils down to ignoring historical performance data.

Evidence Based Scheduling is a good place to start.

Robert Greiner
+1  A: 

Estimating is hard, don't feel too bad if you don't get it right every time.

I used to beat myself up every time I got it wrong but after reading a few books like Code Complete and The Pragmatic Programmer and starting to follow some podcasts (StackOverflow.com for example was put together in the famous "6-to-8-weeks") I found out that it's a common problem.

Whilst there are plenty of books, courses and advice out there (I'm sure you'll get loads of responses) I've found experience is the key, so I'd say try and estimate as much as you can, not just on the big stuff, or the stuff you're getting marked on.

Brabster
+2  A: 

The most important step to learn to estimate is estimating. Begin to estimate and learn about your deviation.

For me, that was the main way to take accurate estimations. Of course, also looking for references and tips.

FerranB
+2  A: 

In my experience, the most successful approach has always been to break down the task into smaller and smaller parts until I feel comfortable giving a time estimate on each individual piece.

Then I add up the total time -- and double it. I find that even with this micro-estimating technique I give myself a little extra on a few things, and WAY too little time on most things. Forcing myself to double the estimate actually turns out to provide a pretty accurate picture of how things will turn out, because there are ALWAYS unforeseen factors and complications in every project.

The other benefit of this approach of course is it gives you a detailed roadmap to follow as you proceed with the project, and if you track your progress on each task using a good project management suite, you're better prepared to answer the question in the future.

Brian Lacy
A: 

This would be good place to start and also this question would provide some insight.

Rachel
A: 

Hofstadter's Law:

It always takes longer than you expect, even when you take into account Hofstadter's Law.

Rachel