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.’”