#NoEstimates – Response to Ron Jeffries

Ron Jeffries posted a thoughtful response to my #NoEstimates video. While I like some elements of his response, it still ultimately glosses over problems with #NoEstimates.

I’ll walk through Ron’s critique and show where I think it makes good points vs. where it misses the point.

Ron’s First Remodel of my Kitchen Remodel Example

Ron describes a variation on my video’s kitchen remodel story. (If Ron is modifying my original story, does that qualify as fan fic??? Cool!) He says the real #NoEstimates way to approach that kind of remodel would be for the contractor to say something like, “Let’s divide your remodel up into areas, and we’ll allocate $6,000 per area.” The customer then says, “I need 15 linear feet of cabinets. What kind of cabinets can I get for $6,000?” Ron characterizes that as a “very answerable question.” The contractor then goes through the rest of the project similarly.

I like the idea of dividing the project into pieces, and I like the idea of budgeting each piece individually. But what makes it possible to break down the project into areas with budget amounts in each area? What makes it possible to know that we can deliver 15 linear feet of cabinets for $6,000? Ron says that question is “very answerable.” What makes that question “very answerable?”

Estimation!

Specifically, we can answer that question because we have lots of historical data about the cost of kitchen cabinets. As Ron says, “Here are pictures of $30,000 kitchens I’ve done in the past.” That’s historical data from completed past projects. As I discuss in my estimation book, historical data is the key to good estimation in general, whether kitchen cabinets or software. In software, Ron’s example would called a “reference table of similar completed projects,” which is a kind of “estimation by analogy.”

Far from supporting #NoEstimates, the example supports the value of collecting historical data so that you can use it in estimates.

Ron’s Second Remodel of My Kitchen Remodel Example

Ron presents a second modification of my scenario, this one based on the observation that kitchens involve physical material and software doesn’t. “Kitchens are ‘hard’, Software is ‘soft’.”

(The whole hard vs. soft argument is a red herring. Yes, there are physical components in a kitchen remodel and there are few if any physical components in most software projects. So that’s a difference. But even with the physical components in a kitchen remodel, the cost of labor is a major cost driver, just as it is in software, and more to the point, the labor cost is the primary source of uncertainty and risk in both cases. The presence of uncertainty and risk is the factor that makes estimation interesting in both cases. If there wasn’t any uncertainty or risk, we could just look up the correct answer in a reference guide. Estimation would not present any challenges, and we would not need to write blog articles or create hashtags about it. So I think the contexts are more similar than different. Having said that, this issue really is beside the point.)

Ron goes on to say that, because software is soft, if the kitchen remodel was a software project we could just build it up $1,000 at a time, always doing the next most useful thing, and always leaving the kitchen in a state in which it can be used each day. The customer can inspect progress each day and give feedback on the direction. As we go along, if we see we don’t really need $6,000 for a sink, we can redirect those funds to other areas, or just not spend them at all. If we get to the point where we’ve spent $20,000 and we’re satisfied with where we are, we can can just stop, and we’ll have saved $10,000.

This sounds appealing and probably works in some cases, especially in cases where the people have done the same kind of work many, many times and have a well calibrated gut feel that they can do the whole project satisfactorily for $30,000. However, it also depends on available resources exceeding the resources needed to satisfy requirements. I would love to work in an environment that had excess resources, but my experience says that resources normally fall short of what is needed to satisfy requirements.

When resources are not sufficient to satisfy the requirements, a less idealized version of Ron’s scenario would go more like this:

The contractor gets to work diligently working and spending $1,000 per day. The kitchen is indeed usable each day, and each day the customer agrees that the kitchen is incrementally better. After reaching the $15,000 mark, however, the customer says, “It doesn’t look to me like we’re halfway done with the work. I like each piece better than I did before, but we’re no where near the end state I wanted.” The contractor asks the customer for more detailed feedback and tries to adjust. The daily deliveries continue until the entire $30,000 is gone.

The kitchen is better, and it is usable, but at the project retrospective the customer says, “None of the major parts are really what I wanted. If I’d known ahead of time that this approach would not get me what I wanted in any category, I would said, Do the appliances and the countertops, and that’s all. That way I would at least have been satisfied with something. As it turned out, I’m not satisfied with anything.”

In this case, “collaboration” turned into “going down the drain together,” which is not what anyone wanted.

How do you avoid this outcome? You estimate the cost of each of the components. Or you give ranges of estimates and work with the customer to develop budgets for each area. Estimates and budgets help the customer prioritize, which is one of the more common reasons customers want estimates.

Ron’s Third Example

Ron gives a third example in which he built a database product that no one had built before. There are ways to estimate that kind of work (more than you’d think, if you haven’t received training in software estimation), but there is going to be more variability in those estimates, and if there are enough unknowns the variability might be high enough to make the estimates worthless. That’s a better example of a case in which #NoEstimates might apply. But even then, I think #AskTheCustomer is a better position than #NoEstimates, or at least better than #AssumeNoEstimates, which is what #NoEstimates is often taken to imply.

Summary

Ron’s first example is based on expert estimation using historical data and directly supports #KnowWhenToEstimate. His example actually undermines #NoEstimates.

Ron’s second example assumes resources exceed what is needed to satisfy the requirements. When assumptions are adjusted to the more common condition of scarce resources, Ron’s second example also supports the need for estimates.

Ron closes with encouragement to get better at working within budgets (I agree!), collaborating with customers to identify budgets and similar constraints (I agree!). He also closes with the encouragement to get better at “giving an idea what we can do with that slice, for a slice of the budget”–I agree again, and we can only provide “giving an idea of what we can do with that slice” through estimation!

None of this should be taken as a knock against decomposing into parts or building incrementally. Estimation by decomposition is a fundamental estimation approach. And I like the incremental emphasis in Ron’s examples. It’s just that, while building incrementally is good, building incrementally with predictability is even better.