Estimating Programmer Time

I've had a few questions in my mailbox recently about this subject -- and as leader of a company that provides software development services, it's one that is dear to my heart. Our usual way of working with our clients is to estimate the time required for any requested programming task, and to guarantee we will come in within 20% of that estimate. So arriving at an inaccurate projection can really hurt. The good news is we've gotten better at it over time; the bad news is that it is not easy, and there will inevitably be occasions when a task takes much longer than expected to complete. Here's what we've learned over the years. 1. The starting point - look at how often you underestimate and compare it to how often you overestimate. You aren't really surprised, are you? All developers have a tendency to underestimate how long a task will take. Programming provides one of the most clear-cut examples of that oft-stated law: "Everything takes longer than you think it will, even when you take this law into account." Understanding the factors that lead to this is the heart of becoming a better estimator. 2. The most important tool you can have handy when trying to estimate is a database of how long things have actually taken you in the past. If you do not track your time - your entire group's time - against specific development tasks, you should start doing that now. 3. Estimate in pairs. Your accuracy will go way up. 4. Here's the key: remember that the bulk of a programmer's time is not spent actually writing the new code, but in (1) figuring out how the existing program works, (2) determining where to make the change, (3) verifying that the change actually works, and (4) debugging any problems found. These are the times that are hardest to control, and are the most often overlooked: novice programmers habitually underestimate the likelihood that problems will emerge in testing. 5. To manage this, include estimates of "design and analysis" time, and "testing" time, and assume some time will be needed for debugging -- even in what seem to be the simplest modifications or enhancements. Remember to include time for defects found not just by the programming team, but by customers and end users after the item goes into production. 6. Be willing to revise the estimate after the initial few hours of the work. Perhaps the estimate was based on the idea that some new components could be dropped quickly onto a form. But it turns out the form is so crowded with widgets and gizmos that it needs to be completely re-structured. If good estimates are needed to track costs or delivery dates, programmers need to become alert to the fact that discoveries which will affect development timelines need to be reported immediately so other stakeholders can revise their expectations. image originally uploaded as http://www.flickr.com/photos/aarongeller/360135019/