I have come to realize that I am terrible at estimating how long a software development task is going to take. I’m like Jeff Atwood with his proverbial 6 to 8 weeks, except that my default answer is “about a month.” The truth is, I’ve let this go on for far too long because I don’t feel terribly bad about my incredible lack of precision. I’ve never tried particularly hard to come up with an estimate I truly believed in. Bad estimates are so common, it never felt like a big problem. Still, I’d hate to think I do this badly simply out of laziness.
In my professional experience, estimates are usually bad for some combination of these factors:
- The developers doing the actual work aren’t involved in the the estimation process.
- When developers participate, they answer with vague platitudes: “about a month.”
Neither the project managers nor the developers are trying particularly hard. To get a good estimate, you have to drill down. It could take some time. But unless the full schedule is well over a year, if you’ve only dug deep enough to estimate with a precision measured in weeks, your estimate is worthless. It’s a form of denial. You’d be in a better position if you acknowledged that you don’t really have a schedule, and dealt more proactively with the ramifications.
I can think of another excuse for my sad estimates. Years ago I read a book by Barry Moltz called You Need To Be a Little Crazy: The Truth About Starting and Growing Your Business. The thing I remember most from this book was an entrepreneur who admitted that if he’d known how much work his own business was going to be, he never would have gotten started. He wasn’t regretful about having to work hard, in fact he felt fulfilled and considered his business a success. He was admitting that if he’d been less naive, he probably would have missed out on his success. This is true about all kinds of endeavors in life: sometimes it’s easier to get started if you don’t think too hard about how much work it’s going to be. Think instead about the potential results. Creating software is no exception. Unfortunately, coming up with a good estimate requires one to examine in excruciating detail just how much work you have to do.
It’s often easier to find some interesting edge of a problem and start there without worrying too much about the big picture. You can build momentum this way, and that ephemeral momentum is of paramount importance in creating anything great. The best work is done in prodigious bursts of enthusiasm. Momentum is key to plowing through the less interesting parts of a project. Nonetheless, particularly when you’re working as part of a team, your estimates are also important. Bad estimates have real consequences.
For a task that’s only a month or two long, I could realistically break it into tasks measured in hours. This is going to reveal a painful picture of every mind-numbing detail ahead, before I have any momentum at all. But in my quest to be a better estimator, I have decided to acknowledge something. This isn’t going to make it easier to procrastinate. It’s going to make it harder. I’ll be able to measure in very concrete terms what I didn’t get done those two hours I was hypothetically reading about some 16-year old in Florida who, God willing, could be the next great Michigan quarterback in 2012. Hypothetically.
