"How long will it take to finish the software?" That question is by far the most vexing one a software will team will get. The software team will think about it, come up with a reasonable estimate and then to be safe multiply that by three. Sometimes you get lucky and this works, and sometimes it is exposed as the voodoo 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?

Is it the programmers that are at fault for the poor estimate? I am not so sure anymore. From my experience 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 those 8 hours are just not consecutive. Nor do they take into account the "unseen" delays that come into every project. What are these delays that need to be added into an estimate?

• 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, CIO.com, 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 have surly behavior. 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.

Most important for keeping a project on time is the role of the project manager. I suggest hiring a former NFL lineman. The PM needs to block all of the outside distractions, extraneous meetings, one-off projects and other items that divert the ocus of the programming team. When the programmers have less distractions you can watch your "sick time" allocation shrink.

Of course, all of this is assuming that the project was well defined to begin with. How to define a project will have to wait for another posting.