Estimates? We Don’t Need No Stinking Estimates!

How a hashtag lit the nerdy world of project management aflame — or at least got it mildly worked up

At 5:53 p.m. on Dec. 10, 2012, Woody Zuill sent out a tweet that read:

#NoEstimates — I’ve added a litte more fuel to the fire

The tweet linked to a blog post he’d written describing a heretical approach to software development — one that omits the standard step of estimating the time and resources a project will need.

Zuill is a software manager for a home irrigation-products manufacturer in Southern California. His choice of hashtag was no more carefully premeditated than his spelling of “little.” With a soft, measured voice, a gray beard and the tight-lipped smile of a veteran optimist, he does not come off as a revolutionary firebrand.

Yet his #NoEstimates hashtag was a magnet for discontented software grunts everywhere, and before long it had become a banner of sorts. Like-minded programmers and managers from many continents flocked to the discussion on Twitter — while software traditionalists and veterans scoffed at the arguments.

Zuill and his #NoEstimates allies say they intend the term as an invitation to a conversation. Vasco Duarte, another #NoEstimates advocate, had been tweeting similar ideas using the tag #EstWaste. But Zuill’s hashtag — with its Marianne-at-the-barricades, “They shall not pass!,” liberty-or-death feel — made a better slogan. So first Duarte and then others ran with it, and it took flight, kicking off what extreme-programming pioneer Ron Jeffries soon dubbed the “NoEstimates Movement.”

When I first saw someone use #NoEstimates, the term brought to mind a scene in a conference room, with programmers staring down a Suit. Arms folded, bristling with defiance, they declare: We will not give you what you want!

Of course, that pretty much never happens. It’s not even what #NoEstimates proponents say they want. They’re talking less about an uprising than a renegotiation of what organizations expect from software developers. They’re well aware that their ideas can come off as impractical and implausible; their slide decks are full of images of rainbow unicorns and Don Quixote. But there’s a firm persistence to their questions.

Like so many programmers before them, they have learned how treacherous it can be to stick a pin in a calendar and say, this is when our project will be done. Can we just stop doing that already?

As long as we’ve been making software, we’ve been screwing up its deadlines. Beginning in the 1960s, as industry began to demand ambitious software projects, programmers began to find that the harder they tried to deliver polished work on time, the more miserably they failed. In the 1960s Frederick Brooks, tasked with leading a massive IBM programming project, famously discovered that adding more programmers to a late software project only makes it later.

Well, that sucked.

The annals of software-project history are packed with epic train-wrecks. The best-documented ones are in the public sector, including the FAA and the FBI and Healthcare.gov. Private industry is better at keeping its pain to itself, but when the full tales of slow-motion belly-flops like Microsoft’s Windows Vista get told, it isn’t pretty. The most-cited numbers on software-project failure are those of the Standish Group, a consulting outfit that reported that in 2012 only 39 percent of software projects were considered “successful.”

Late software projects run up costs, incur collateral damage and sometimes take down entire companies. And so the software industry has devoted decades to waging a war on lateness — trying frontal assault, enfilade, sabotage, diplomacy and bribes, and using tactics with names such as object oriented programming, the Rational Unified Process, open-source, agile and extreme programming.

Estimates play a part in nearly all of these approaches. Estimates are the siege-engines of the war on lateness. If we use them carefully and patiently and relentlessly, the hope is, maybe, eventually, we’ll win.

Why is software so late? One venerable intellectual tradition in the field says the answer lies in software’s very nature. Since code costs nothing to copy, programmers are, uniquely, always solving new problems. If the problem already had a solution, you’d just grab a copy from the shelf. On top of that, we have a very hard time saying when any piece of software is “done.”

These were the points raised by physicist Aaron Santos when I turned to him for help understanding the #NoEstimates controversy — he’s the author of a book titled How Many Licks? How to Estimate Damn Near Anything. He said software development is less like other engineering fields and more like basic scientific research, where estimates are to laugh: “An equivalent question from my field would be, ‘Estimate the amount of time it will take for us to discover what dark matter is.’ I have no idea how long that will take! With problems we’ve never faced before, the usual techniques of estimation don’t always work.”

There are lots of ways to try to do software estimates, but most of them look like this: First, you break your project down into pieces small enough to get your head around. Then you figure out how long each of those parts will take, breaking them down further into smaller pieces as needed. Then you add it up! There’s your estimate.

You can do this all at once up front — that makes you a “waterfall” type, who likes to finish one thing before you start another. Or you can do it in little chunks as you go along — that’s the style popular today, because it gives you more room to change course. Teams around the world now use the agile “Scrum” technique, in which programmers consult with “project owners” to divide work up into “stories,” then eyeball these stories to guess how long they will take and how many can fit into a (brief, usually two-week) “sprint.”

In this world, putting detailed days-and-hours estimates on stories is out of fashion; teams pick from a slew of different guesstimate styles. They assign “points” to each story, or they take a “shirt sizing” approach, assigning each story a label like S, M, L, XL. You will also find teams playing “project poker,” a blind-bidding technique in which developers write their estimates on the backs of cards so that their guesses aren’t influenced by whoever went first.

Some developers swear by these techniques; others roll their eyes at what they see as fashion trends in the fickle programming marketplace. The trouble remains: However you arrive at them, software project estimates are too often wrong, and the more time we throw at making them, the more we steal from the real work of building software. Also: Managers have a habit of treating developers’ back-of-the-envelope estimates as contractual deadlines, then freaking out when they’re missed. And wait, there’s more: Developers, terrified by that prospect, put more and more energy into obsessive trips down estimation rabbit-holes. Estimation becomes a form of “yak-shaving” — a ritual enacted to put off actual work.

That, at any rate, is the #NoEstimates case. The #NoEstimates people say, let’s call off the interminable siege. Let’s spend our time more usefully.

Zuill recommends quitting estimates cold turkey. Get some kind of first-stab working software into the customer’s hands as quickly as possible, and proceed from there. What does this actually look like? Zuill says that when a manager asks for an estimate up front, developers can ask right back, “Which feature is most important?”—then deliver a working prototype of that feature in two weeks. Deliver enough working code fast enough, with enough room for feedback and refinement, and the demand for estimates might well evaporate. That’s how Zuill says it has worked for him for more than a decade. “Let’s stop trying to predict the future,” he says. “Let’s get something done and build on that — we can steer towards better.”

Duarte and Neil Killick, an Australian software consultant who is another #NoEstimates champion, favor a less total version of the approach. Duarte, who has written a book on #NoEstimates, argues that teams should dive in and start working, and after a few sprints, they’ll be able to provide more useful forecasts.

Neither wing of the #NoEstimates party can point to a slew of real-world examples of their vision in action. Duarte’s book tells the tale of a #NoEstimates project, but it’s fictional. There is no iconic “No Estimates project” that proponents can cite, the way that the Chrysler C3 project served as the iconic testbed for extreme programming.

So there isn’t a ton of verifiable data that #NoEstimates advocates can point to when their ideas provoke vehement takedowns — like this four-part series by Seattle-based IT veteran Peter Kretzman. His message, distilled, is one you hear in many #NoEstimates critiques: Grow up! The rest of us have to deal with the hard realities of planning. Why should we give in to the pleadings of pampered programmers?

This resentment perplexes Zuill and his allies. Zuill might look like a just-wing-it kind of guy — he begins talks by apologizing that he’s “not a very time-conscious person” — but he’s adamant that #NoEstimates doesn’t mean no discipline, and so is Duarte. “The market imposes deadlines on companies,” Duarte says. “These are beyond their control. [But] trying to use estimates to meet those deadlines is a losing battle.”

I asked Santos, the estimation expert, whether he could think of any other example of professionals rebelling against estimates. He had to think hard. “There was that time in the early 2000s when Bush and Cheney said they had no idea how much the Iraq war was going to cost, but that’s about it,” he answered. (February, 2003: “The White House maintains that any estimate now would be no more than a guess, since the timing and length of war, and the duration and nature of post-war peacekeeping and reconstruction, are unknown.”)

After reviewing the #NoEstimates debate, I found myself ambivalent, torn between its two poles: Detailed estimates or Let It Go? Confucius or Lao-tse? Old Testament or New? Felix or Oscar?

I wanted a second opinion from someone who’d thought deeply about these questions, but whose fingernails were grimy from the trenches. So I reached out to John Allspaw, an expert in systems and scaling. I’d worked with him years ago; today he’s Etsy’s SVP for infrastructure and operations. Allspaw shared my ambivalence but laid out some concrete objections to the #NoEstimates case.

#NoEstimates is an example of something that engineers seem to do a lot, Allspaw said — “communicating a concept by saying what it’s not.” The hashtag undermines the kind of critical thinking the movement says it aims to foster and communicates a resolve that advocates don’t stand behind. “If you want to rally behind something that has ‘no’ in it, it means that you’re against something. So you show up at the picket line. You’ve got your protest sign all written up. Then you look around and everyone’s saying, ‘Oh, no no no, we’re not against it — we just want to get a deeper understanding of what all the tradeoffs are.’ Then you’re like, Oh fuck, what am I doing here? I thought it was a party!”

Allspaw argues that the work of estimation, however frustrating, is a valuable part of the research-and-discovery effort that all software projects must make. Sure, you learn as you build; but you also learn as you estimate.

“Say I’m gonna add geolocation to searches. So I make an estimate: this is gonna take me about a month. It’s super-informative, not just for me but for other parts of the organization, to encapsulate why I think it’s going to take me a month.” Maybe you’ve never done geocoding, so you need extra time to learn it; or maybe geocoding’s easy for you, but you have a hunch there are going to be problems with the user interface, so better expect to work longer on that. “In making that estimate, I’ve now told you a whole bunch about what’s important to me and what my assumptions are. And when I’m done and I don’t hit that month, I know some things I didn’t know before: geocoding’s a lot easier than I thought. Or a lot harder.”

Allspaw also points out that the yearning to break the bonds of estimation is nothing new — he’s fond of quoting a passage from The Unwritten Laws of Engineering, a 1944 manual which says that engineers “habitually try to dodge the irksome responsibility for making commitments.”

#NoShirking! The duty of estimation, according to Unwritten Laws, must be faced head-on: “No one should be allowed to avoid the issue by the old formula, ‘I can’t give a promise because it depends upon so many uncertain factors.’”

As a writer, I like to think I’m a professional, and I’ve generally been pretty good at guessing how long pieces would take to finish. (My training: Years of writing theater reviews in the middle of the night for overcaffeinated copy editors who couldn’t go home till I filed.)

Lately, though, I’ve begun to slip. My last couple of pieces here at Backchannel were seriously late. This time around, I thought, better tackle something short, fun and easy to complete. #NoEstimates looked like a good bet.

Hah! There was two-years-plus of a Twitter debate to catch up on. Countless blog posts to review. Busy people to collar. When I started, I had no idea there was a whole #NoEstimates book I would want to read. I ended up arriving with you at this sentence a good 10 days later than I’d told my editor I would.

So, sorry, I’m not going to sit here and keep trying to devise a snappier conclusion. I think I better just turn something in. Maybe I’ll estimate better next time.

Illustrations by Cristóbal Schmal
Follow Backchannel: Twitter | Facebook