We asked three programmers to share their takes on effort estimates.
Reddit Senior Director of Engineering KD Bhulani said each developer on his team starts projects with what he called a “scientific, wild-ass guess.”
SquareFoot CTO Joshua Vickery said traditional estimates provide the bad package deal of “poor predictability” and a “false sense of confidence,” which “is worse than not knowing.”
Kent Beck, whose extreme programming paradigm changed the way many programmers approach estimates, is over the whole thing.
“I choose not to play that game,” he said. “But I’m working from a position of considerable privilege. I can just say: ‘Yeah, piss off. I can’t tell you, so I won’t.’”
THE BAD HABIT WE CAN’T QUITE SHAKE
And there you have it.
The arithmetic estimation approaches of yore have given way to #NoEstimates, a charge spearheaded by programmer Woody Zuill that is exactly what it sounds like, and general estimation malaise. Check “software development effort estimation” on Wikipedia and find an entire section dedicated to disparaging jokes, like this one from Fred Brooks: “What one programmer can do in one month, two programmers can do in two months.”
What is it about software that makes estimates so impossible?
First, Vickery told me, it’s not a software-specific problem: “If you ask someone when their kitchen renovation is going to be done, the common answer is that it’s twice as long as the contractor says, right?”
“You don’t have to estimate. You just have to not die.”
Second, estimating isn’t impossible, Beck said. It’s just usually inappropriate. His “explore, expand, extract” theory describes companies in three different stages of growth. For established, successful companies in the “extract” stage, estimating makes sense because they’ve likely completed similar projects before. For companies that are exploring or expanding, estimates don’t provide value, because they’re not based on any real experience.
“You don’t have to estimate. You just have to not die,” Beck said.
But, as he acknowledged, the “piss off” response isn’t an option for everyone. In most workplaces, estimates come with the job, and developers don’t get to opt out entirely.
Often, there’s a good reason managers or colleagues want an estimate — maybe the company’s hiring plans rely on it, or there are dependencies with other projects. Other times, there’s a bad reason — like the desire to boost productivity at any cost or grab interdepartmental control by manipulating timelines.
Either way, estimating is here to stay (for now). But that doesn’t mean it has to run the show. Let’s survey what can go wrong when estimates are used inappropriately. Then, we’ll take a look at a better, middle path.
SYMPTOMS OF WRONGHEADED ESTIMATING
Beck hasn’t kept up with evolving debates around estimates.
“It’s such a divisive topic, and I just don’t think it’s terribly important,” he said.
Just because someone demands a date or a dollar number doesn’t mean developers have to respond in kind, according to Beck. The estimation conversation contains a multitude of other considerations, like “Is this project worth doing?” and “How can this team demonstrate its value?” Those considerations often get masked by hand-wringing about timelines.
Here are some things that happen to teams that get sucked into estimate tunnel vision:
THEY WAIT TOO LONG TO KILL BAD IDEAS
Like Vickery said, estimates give an illusion of certainty. Once something gets labeled a four-month project, the odds are good it will take four months.
But what if everyone on the team knows the project is a disaster after just one month?
Sometimes, estimates incentivize orgs to cling to ill-fated projects. A better way, Beck said, is to approach everything in increments, so projects can be tossed out or reworked at any time, no matter their scope.
“I don’t want a nine-month project. I want nine one-month projects,” he said. “And then if you tell me I have nine one-month projects, I’m going to say that each month is going to be four week-long projects, just because I always want that feedback loop.”