McCarthy’s Four Laws of Software Estimation
“Developers,” said my friend Mac, “are really bad at guessing how long it takes to write software.”
Michael “Mac” McCarthy and I go back to the mid-1980s. What Mac likes to do most, beyond enjoying a fine Chardonnay and talking politics, is making observations about the world of technology. While he’s not a programmer himself, he has worked closely with them for years, and has managed many software projects at media companies and startups.
Over the course of a delicious lunch today at Harry’s Hofbrau in Foster City, Calif., Mac shared some good stories about his experiences with corporate development teams. As part of that, he stated some principles that, with his permission, I’ve repackaged and labeled as “McCarthy’s Four Laws of Software Estimation.”
The First Law: If you ask a developer for a project estimate, and if he thinks the project is a good idea or would pose an interesting challenge, then he’ll say, “three weeks.”
The developer has no idea how long it will take, but “three weeks” sounds encouraging enough that you’ll probably go ahead with the project.
The Second Law: If you ask a developer for a project estimate, and if he thinks the project is a bad idea or wouldn’t be fun to work on, then he’ll say “six months.”
The developer still has no idea how long it will take, but “six months” sounds negative enough that you’ll probably say “in that case, never mind.”
The Third Law: Whether the developer estimated “three weeks” or “six months,” if the project proceeds it actually will take a minimum of nine months.
That’s because, Mac says, developers are bad at software estimation.
The Fourth Law: When asked why the project is behind schedule, the developer will blame inadequate or incomplete specifications.
What’s your experience — are developers good or bad at project estimation? Do their estimates vary depending on whether they like the idea or not?
I hope the scenario isn’t just “ask a developer”. Estimating a non-trivial project is itself a project requiring data gathering and analysis of specifications and availability of existing data, reusable software, and staff to do the job. If you don’t fund and staff that first project, and just ask for an off-the-cuff guesstimate then the 4th Law (“bad specs”) is entirely the right answer – and the person asking gets no better than he deserved. Or did the manager lean on the developer to answer with a completion date that met the schedule he promised his boss.
Pose this question another way: are managers bad at initiating projects? Or at the least, fail to understand what it takes to do this properly.
Have a read of a book called “Agile Estimating and Planning” by Mike Cohen.
Software estimation for a complete project is impossible, but software estimation for a smaller increments is doable and reliable. The trick is not to ask just one person, but the team (including QA, tech pubs).
In general trying to ship a product with a fixed set of features with a set date will always miss the date, in my experience. But shipping a product with a fixed date and variable content using Agile/Scrum is repeatable.
Based on the limited information a client gave me about a task once, I estimated “between a week and six months.” They didn’t find that helpful, and in fact it became the source of some not entirely good natured ribbing in the weeks to come. Well, I stand by it. It was a reliable estimate. 🙂