Steve McConnell on #NoEstimates

The justly famous Steve McConnell has weighed in on #NoEstimates. He’s really quite reasonable and thoughtful. I wish all the critics did such a good job, including me, when I offer criticism. I do draw some different conclusions.

Go check out his video first: I’ll see you in 15 minutes.

Welcome back …

The hashtag #NoEstimates is really terrible: it’s so binary. Unless, of course, you were trying to bring attention to an important concern and an idea you found useful. In that case, it’s a great hashtag. It even got the unjustly famous me, and the justly famous Steve McConnell, thinking and talking about it. That’s a darn good hashtag.

Now in my long career, I’ve tried a lot of things, and tried to learn from my betters. Looking at the array of books Steve shows at the beginning, I’m proud to say that at least four of them, including Software Estimation, grace my library, and that I’ve actually read them. I wouldn’t have dipped into that stream four times were there not good ideas there.

I can think of only one reason why I would have read Software Estimation: I was having trouble with software estimation. And I happen to know what that trouble was. We were building a large database product: not one that used a database, but one that implemented a relational database capability. Storage, language, the whole bit.

This effort included quite a few unknowns. They fell into two classes. The basic technology had to be invented. There were things to read, of course, from Codd and Date and all those people, but the implementation of relational still had to be worked out and pushed into code. At the same time, our marketing and sales people, and our own understanding, were causing us to identify new “requirements”, and new priorities, all the time.

We were a small company, I suppose middle tens of millions in revenue at that time, and we needed the product NOW. Everyone was on my case asking when we were going to be done, and all my estimates were taken as promises and none of them came true. I thought I needed help estimating and turned to Steve’s book among others. I was following Steve’s advice in the video: if your estimates are inaccurate, you obviously need to get better at estimating.

That’s actually the premise that the #NoEstimates folks want to question. Possibly you need to get better at estimating, but possibly you need to get better at other things.

The Kitchen

Steve includes a long conversation between a #NoEstimates kitchen contractor and a couple who want to redo their kitchen for $30,000. The conversation, which I’m pretty sure he made up, is going to get the contractor fired, if the couple have a clue, or to get them an unsatisfactory kitchen if they spend all their money on cabinets.

There are two issues with this example.

It’s made up!

First — as designed, and I do this too so I’m not criticizing the choice — the dialog shows how silly a hard-line #NoEstimates approach would be. The dialog is spot on, however: Steve has been reading the Twitter stream quite carefully. So if a real #NoEstimates person were ever to say in a real situation what they say on Twitter, there would be trouble. But on Twitter, they’re trying to open people’s minds to alternatives, so they block any attempt to make the answer be “let’s estimate”. That’s not because they would never estimate. Every #NoEstimates person I’ve encountered has always said that if you have to estimate, you should estimate. No one has suggested being a jerk, although some of us manage to do it even without advice.

There’s a budget!

In the kitchen scenario, the couple has a budget. The contractor seems to ignore that fact completely, and that’s bad. A much more useful thing to do would be to have a discussion on the rough proportioning of money across cabinets, counter tops, flooring, sink and faucet, and appliances, to get a balanced kitchen. A $29,000 counter top, delightful though it might be, would not be a good starting point.

Even a simple approach to this would change the conversation. We’ve got five areas of interest. Let’s assume we spend $6,000 on each. What kind of cabinets can we get for that amount? What kind of flooring? And so on.

Now the pastiched¹ contractor would start saying well let’s build this cabinet right here and see how we do and you can stop when you run out of $6,000. But I don’t think you could get even the most rabid #NoEstimates person to do that. It’s not a survivable strategy. #NoEstimates people may be crazy, but they’re not stupid.

A budget changes the conversation.

But what you could do would be to change the conversation from “how much do cabinets cost”, which is an unanswerable question, to “if I need 15 linear feet of cabinets, what kind of cabinets can I get for $6,000”, which is a very answerable question and actually helps the customer make decisions.

And those decisions are the ones #NoEstimates wants us to make: what do we want? Not how much will it cost: what, within this budget, do we want?

So if I were writing the kitchen scenario in my best attempt at a #NoEstimates style, it’d go a different way, much more productively. Because yes, we really do value customer collaboration, not just fake collaboration. So we’d work to get to a point where we can truly collaborate.

It turns out that the best answers on the kitchen will not come from estimating, but from collaborating, from building a common understanding of what we can get for a budget. We do that by slicing down the product, partitioning the budget, and asking “what kind of counter top can I get for six large?”²

It’s a kitchen! We’re doing software!

Far more important, kitchens are not made of software. Construction metaphors have been used in software for a decade and a half, and they’ve never worked really well. It’s too easy to rely too much on a weak metaphor³.

Software is soft. When we build a cabinet, we really can’t build it out of cardboard and then refine the cardboard to particle board and then put a bit of a walnut stain on it and then realize it’s too dark and too cheap and convert it to cherry, all for the cost of a cherry cabinet.

In software, we can. We can build a thin but capable system, refine its functionality, improve its internal design, grow the system, and do it for about the same cost as going directly to the final result. This does require skill, but no not much more skill that it would require to go direct. And often we do it for less, because believe me, when those people see what kind of sink they can get for $6,000, they’re going to reallocate those funds right now. Maybe to counter tops. Have you thought about enameled lava? It’s only about $350 a square foot …

If we’re good enough …

So when we do a software project most important thing first, we wind up doing repeated sweeps over the whole product, top to bottom, left to right, at each point along the way having the best possible whole kitchen for $1000, 2,000, and so on. Yes, this does require skill. Maybe we can’t always do it. Maybe there are teams who can’t do it at all but who can somehow magically use waterfall to get something good. We’re not here to talk about whether Agile works. We’re here to talk about estimates.

For my purposes, the key observations about the kitchen scenario are:

• it’s an unrealistic example of how a #NoEstimates person would deal with a project if it was a kitchen,
• even on a kitchen a #NoEstimates person would move to slicing, and
• kitchens are hard, software is soft.

If your customer wants estimates

Steve makes the point early on, and hammers it in later, that if your customer wants estimates, you should do estimates. This is a very common response when we talk about this topic and I think it’s almost always not as right as it might be⁴.

Our customer has a purpose and some constraints. Our job is to help them attain that purpose, within those constraints, through collaboration. The kitchen people’s purpose is to get a better kitchen, and the constraint is $30,000. The contractor needs to help them, and it seems almost certain that the best way to help them is to assist them in understanding how to allocate money to the various aspects of the kitchen, not just to “estimate”.

And in a real kitchen situation, the contractor would ask lots of questions intended to create mutual understanding of what could be done. When we can, we need to do that in software.

When I was building that database product, there was no last time. It had literally never been done before, certainly not by our team and as it turns out, by no one else. There was no data to base estimates on.

Our mistake — my mistake — wasn’t an inability to estimate. It was an inability to build the product incrementally and get it out there in the hands of people who needed help.

Had I been able to do that, the customers would have been happier, revenue would have increased sooner, sales and marketing would have gotten off my back, better decisions would have been made, and I’d probably be driving a much better car.

For the problem for which I bought Steve’s Software Estimation book, my bottom line is:

I didn’t need better estimates. I didn’t need estimates at all. I needed earlier, more incremental delivery.

Interestingly enough, I still don’t know a good way to estimate something that has never been done before, after reading Steve’s book and Mike’s book and a lot of other books.

I do know how to build things incrementally and even if I knew how to estimate building the thing incrementally seems to me to be a better answer. Still, don’t get me wrong:

We Do Often Need Budgets

Imagine a different scenario for the kitchen. Folks say “We have a budget of $30,000”, and the contractor says:

“Great. Here are some pictures of $30,000 kitchens that I’ve done in the past. There are some pictures of kitchens that cost much less, and much more. That will give you an idea of what’s possible.

“But there’s more. Unlike most contractors, who will tear out your kitchen and give it back to you in a month or so, I’ll make sure your kitchen is usable all the time. You can cook in it every day. Every Friday, voila! I’ll install the improved kitchen while you sleep, and next morning you can make breakfast as usual. We’ll do the improvements in the order you want and the kitchen will always be in working order.

“In addition, if we get, say, $20,000 in and you think the kitchen is good enough, we can stop right then. Everything will always be properly installed and in good order. So if we see ways to defer things we really don’t care about and then decide not to do them at all, or to do them less expensively, no problem.”

Now that’s the Agile #NoEstimates contractor I want to deal with. In kitchen world, that’s probably not possible. In software world, it probably is.

Conclusions. Ish.

I draw different conclusions from Steve’s⁵.

We agree that the problems with estimates are real. Steve suggests getting better at estimates and says that when the customer wants estimates, we should estimate.

I would suggest a different path⁶.

Let’s get better at working within budgets, and at collaborating with customers to identify budgets and similar constraints. Let’s get better at slicing up what needs to be done (cabinets, counter tops, etc) and at giving an idea what we can do with that slice, for a slice of the budget.

This is something that can be done where we have experience, even when we don’t have enough numbers to do one of those fine probabilistic estimates that the big guys know and love. And it will engage our customers in solving the problem and dealing with the constraints better than it would if we just gave them an estimate for the kitchen.

What about when we don’t have experience?

Sometimes we really do need to just find our way. In large and small organizations, many software efforts are done with little or no historical information. No amount of “estimating” is going to get a valid answer, because the experience isn’t there to ground things.

In these situations, what if we can slice and dice the project? Can we do experiments to try things and to learn? In essence we have no real choice but to spend money to get experience. If we can learn to do that well, by building a real product incrementally, we can generally get some product value for that money, not just information value.

Maybe at the end of that time, we’ll have estimates and maybe we’ll be better at estimating. If so, honestly, I don’t think that will matter.

If we can learn to build incrementally, with an eye to a sliced down product with allocated slices of budget, we’ll get a product we can examine, play with, and even deploy, long before the budget is consumed⁷.

That’s more valuable than being good at estimation. That’s what the #NoEstimates conversation is about, in my opinion.

Thanks!