Software estimation is really hard. I’ve never encountered a programmer who’s good at it. I don’t think such a programmer exists. I myself am not good at estimation nor do I expect ever to be.
Here are two tactics that I use to deal with the challenge of estimation.
- Try to make estimation as irrelevant as possible
- Try to use historical data to make future estimates
Try to make estimation as irrelevant as possible
I figure if I’ll never be able to estimate accurately, at least I can try to make estimates a less important part of the picture. Probably my most successful tactic in this area is to try to only take on projects that last a matter of days. If a project will take more than a matter of days, then I try to break that project up and identify a sub-project that will only take a matter of days. That way, if I estimate that the project will take 2 days and it really takes 4, no one has “lost” very much and nobody’s too upset (especially if I let my stakeholder know that I have very low confidence in my estimate).
Try to use historical data to make future estimates
Obviously all estimates are based to an extent on historical data because you’re basing your estimates on past programming experiences, but there’s a little more to it than that. When I work on a project, I break the work into individual features. I have a sense for how long a feature will take on average. Even though some features take an hour and some features take three days, a feature takes some certain amount of time on average. If I think the average amount of time I take to build a feature is half a day and my I can see that my small project has 5 features, then I can estimate that my project will take 5 * 0.5 = 2.5 days. Obviously there’s a lot of room for inaccuracy in this methodology, hence tactic #1.
If you really want to go deep on estimation, I recommend Software Estimation: Demystifying the Black Art by Steve McConnell.