Estimating the amount of time needed to complete a software project has been a mystery since the beginning of software projects. The most oft-used method I've seen, and at times used myself, is multiply by 3. Ask the programmers how long the project will take and then multiple that by 3. Sometimes you get lucky and this works, and sometimes it is exposed as the fraud it is.

Why is it that programmers cannot seem to provide a reliable estimate for the completion of a task? Other aspects of a software project can be reliably estimated. QA can be estimated based on how many functions, and user scenarios are needed to test. User testing can be estimated based on number of participants in a study. Documentation can be aligned to how many features and functions need to be documented. So why is it so hard to estimate programming time and why do programmers have such a hard time trying to do it?

Having worked on a number of projects I am no longer convinced that programmers cannot create reasonable estimates for completing a project. In fact if a programmer tells you it will take 8 hours to complete a function, odds are it will take 8 hours. The problem is that programmers tend to be optimistic and do not take into account that the chances of getting 8 hours of undistracted work are nil. So what are the distractions that need to be added into their estimates?

• Sick time - everyone gets sick now and again. Or, as I've had, claims of illness when in reality they take the day off to take their kids to the auto show.


• Small projects - programmers, more than it seems most professions, are often asked to tweak/add/consider/test a bunch of small projects. Some of these have merit and some are just the musings of their manager. All of them slow down the larger project.


• Research - programmers are like guitarists, they can do it faster and better than their peers. The problem is that they never consider that they need to research how they will accomplish the task. Nor the cheapest place to get Aquanet and spandex.


• Debugging - after building superCoolApp1.0 programmers want to work on superDuperCoolApp1.0 and not fix the mess they made in building just plain ole superCoolApp1.0. Well mommy ain't around to clean up their messes so someone has to.


• General Distractions - Slashdot, Ars, The Register, the Apple Store, darts, nerf guns, etc. Blowing off steam is good. Add it to your estimate just do not abuse it. Please.


• Meetings - regular check-in meetings are good for a project team. Keep them short and focused on just providing updates. More often than not programmers get sucked into meetings with folks whose only purpose seems to be holding meetings. Meetings that start 15 minutes late, have no clear purpose, have no actionable items and take 30 minutes too long are the types of meetings that cause programmers to kill. Meetings are by far the number one thing that programmers have asked me to be excused from. It seems they cut into ditching work and going to the auto show time.

Now the million dollar question is how do you estimate for all of the bullet points above? Well some are easy. Add in specific time for research, debugging and check-in meetings into the project plan. Others, if you are managing the project, you need to put on your football gear and clear the lane. Clear the lane of too many outside distractions, squash inconsequential meetings and slap down lesser projects. If you do that you can watch your "sick time" allocation shrink.

Of course, all of this is assuming that the project was well defined to begin with.

Now, just how long does it take to research the unknown?