I’ve spent more energy than I’d like recently fighting because of #NoEstimates. I’d like that to stop, but I recognize how the name #NoEstimates leads easily to fighting. I’d like to make a few comments about that.

I leave these articles about #NoEstimates on this blog purely for reference. I do not use the hashtag. I do not belong to “the movement”. I believe that, for many projects and people, estimating anything smaller than about 3 months’ work is probably a waste of time and energy on average. I’m happy to discuss that with people who want to learn more, but not with people who have just discovered the hashtag and wish to tell me that “no estimates” is stupid. Please read what I’ve written so far on the topic, and then if you have questions, please ask. All “criticism” will be ignored. All inquiry is welcome. (If you don’t understand the reasons for this, then please don’t waste your energy nor mine.)

I wrote recently that I like #NoEstimates as a “pattern interrupt”, meaning that I want people really to sit up and take notice. I feel so strongly that so many people are so mindlessly using so many estimates for harm rather than good, that I accept the risks associated challenging them by “getting in their faces”. Fighting over the estimates themselves traps people in miserable jobs, and that either exacerbates or promotes serious problems like depression. This stuff matters to me.

I’ve Seen This Before…

I think about the name #NoEstimates similarly to the way I think about the name Extreme Programming. I look back at the name “XP” as a marketing tool that did its job: it attracted innovators and early adopters (in the Crossing the Chasm sense), creating a community of people who wanted to work differently and found this one particular set of practices, principles, and values helpful. At the same time, it infuriated many people. Do you remember the jokes about programmers heliskiing? Beneath the surface, though, “extreme” lay at the heart of what we did differently: we took practices that we found valuable and stretched them as far as we could go, to see which ones helped more and which ones didn’t. While some found the word “extreme” laughable, we tried to feel it deeply. This probably still creates tension: we wanted to create a thing of beauty, and those people made it their mission to shit on it. Or maybe they were bored; I don’t know. I hope that something deep motivated books like Extreme Programming Refactored and the unnervingly emotional reviews that accompany it on Amazon.

Of course, the name Extreme Programming lends itself to differences of understanding and interpretation1. The word extreme has many meanings: some positive (“dedicated”, “ardent”), some neutral (“acute”, “severe”), some frivolous (“adventurous”, “adrenaline junkie”), and some negative (“zealous”, “closed-minded”). Many different people can align themselves with extreme for different reasons, and so we might spend a lot of energy arguing simply about which understandings of extreme “are good” or “are bad”.2 We even spend energy arguing about whose understanding of extreme “is correct”, and what extreme “is about” and “is not about”.

Remember this?

“I don’t know what you mean by ‘glory,’” Alice said.

Humpty Dumpty smiled contemptuously. “Of course you don’t—till I tell you. I meant ‘there’s a nice knock-down argument for you!’”

“But ‘glory’ doesn’t mean ‘a nice knock-down argument’,” Alice objected.

“When I use a word,” Humpty Dumpty said, in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.”

“The question is,” said Alice, “whether you can make words mean so many different things.”

“The question is,” said Humpty Dumpty, “which is to be master—that’s all.”

Alice was too much puzzled to say anything, so after a minute Humpty Dumpty began again. “They’ve a temper, some of them—particularly verbs, they’re the proudest—adjectives you can do anything with, but not verbs—however, I can manage the whole lot! Impenetrability! That’s what I say!”

As much as it sometimes pains me to see how some people use a language, how they use the language defines the language. Bringing this back to a less esoteric point, the very notion that “a word ‘means’ something” stands as a convenient shortcut for the more-accurate-but-too-annoying-to-say-daily “in a context that I can reasonably imagine, I can imagine reasonable people using that word to mean this concept”. Although, now that I think about it more, sometimes it stands as a convenient shortcut for “in my current context (because nothing matters more than my context), I expect that when someone uses that word, they mean one of these concepts, and not that stupid idea you’re describing now”. You see: it even depends on your meaning of “means”.

Turning back to Extreme Programming, and knowing that we have so many ways to understand “extreme”, it pains me to point out that when XP folks say “extreme programming”, I think they generally mean something more than “just programming” by the word “programming”.

Sigh.

As I understand it, the word “programming” appears in Extreme Programming to stand in opposition of the tendency to focus software development activities on non-programming tasks, like planning, documenting, meeting, arguing, and the like. The name Extreme Programming might remind us that among all these activities, only one remains essential to delivering software: programming. You can do all the other things well, but without the programming, you have nothing to sell. You can do all the other things poorly, but as long as you build something, it might sell. So, the “programming” in Extreme Programming refers to the essential nature of programming, while the “extreme” encourages us to ask the question, “How close can we get to doing nothing but programming?” or, perhaps better, “How close can we get to doing only the essential parts of this work?”

Naturally, we discovered that some non-programming tasks help us deliver good software: testing, communicating, understanding the business, delivering frequently… and we promptly redefined “programming” to include all these things. At a minimum, some people redefined “programmer” to include a person who does all these things well and sensibly. That, of course, as opposed to “coder” or “code monkey”.

Sigh again.

So in Extreme Programming, we behave in a way that we label “extreme”, but don’t worry, it’s not the bad kind of extreme, but rather the good kind of extreme, and we do “programming”, but programming of course means more than just programming, because only an irresponsible, lazy programmer just programs!

With all this ambiguity, Extreme Programming should never have made it off the ground. The name admits too easily to knock-down arguments from skeptics, and even proponents find far too much room to argue about the details. So why do we still talk about Extreme Programming fifteen years later?

Value Beyond the Name

Practising extremely has helped me develop some fantastic habits. I do higher-quality work (of all kinds) because I take time to think about how I will check my work before I do it. I do more things with less stress, in part because I ruthlessly reject work beyond my capacity, I focus on completing small tasks over undertaking large projects, and I build a clear picture of what “the end” looks like before I start. I do these things even in situations where the average person would consider it overkill. I do them well, regularly, and comfortably, because I’ve practised them for over a decade. I feel happier as a result.

Also, think of programming as more than just programming has helped me enjoy delivering software more. I feel less like a cog in the system and my work has a greater effect on people. I’ve learned much more than the latest programming languages, the most recently-minted frameworks, and yet another damn insane platform to support. This has helped me meet and relate to more interesting people, many of which have become my friends. I feel happier as a result.

I say all this not to pitch you Extreme Programming, but rather to explain that in spite of the obvious naming problems, XP has had an overwhelmingly positive influence in my life. Here, I mean more than just XP the concept, but also the spirit and the community. I see the same potential for #NoEstimates.

So now we come to the same problem with #NoEstimates. The name obviously admits similar arguments about understanding and interpretation. This makes it easy for skeptics to set up a straw man in order to knock it down, and I can’t really blame some of them for going after such an easy target. Even so, I find great potential value in both the name and the concept, and so let me clarify what I think I mean.

As a few of my friends and fellow XP proponents balked at the words “no” and “estimates”, I started looking for ways to relate #NoEstimates to some other similar-sounding concept that I suspected we agreed on. I found this:

Said differently, I don’t use “no” here to mean “never”, but rather “How few can we get away with?” Someone has accused me of using the word “no” in an “Orwellian” fashion, because it doesn’t really mean “no”. Perhaps not, but I don’t use “no” as code for “yes”, but rather to mean “as little as possible” or, if you prefer, “asymptotically no”.

Next, when I say “estimates” in this context, I mean task-level cost estimates, usually given in either “points” or “hours” or “days”, sometimes “weeks”. I mean detailed estimates of the cost of delivering a particular solution. I very specifically mean the typical enterprise-caliber ritually-produced task-level estimates that inevitably someone will turn into a commitment. I mean this:

If you already know the cost, then why are you asking me?

I do not mean “never estimate anything ever”. I don’t view software delivery as art, and I’m not looking for a patron. I do, however, believe that we have better options than producing task-level estimates for managing software projects:

  • Limiting investment exposure through frequent delivery.
  • Limiting investment exposure through committing late and retaining a realistic option to cancel the project.
  • Delivering higher-value features sooner to increase short-term cash flow.
  • Exploring higher-risk aspects of the system sooner to protect against nasty surprises at inopportune times.
  • Monitoring our stress levels to promote working at a pace just short of “too fast”.
  • Relentlessly splitting features into smaller pieces to distinguish the essential parts from the inessential parts.

I know more, but this list suffices. I don’t need to produce a single estimate to do these things well, and I further argue that in many contexts where people typically estimate, they could use these tools to solve their problems more effectively. I invite you to try them. I invite you to tell me why you don’t feel comfortable trying them, because perhaps I can help you find a safe way to try them. I see great potential for drastically improving the way we work.

Even so, to fund a project, we’ll probably need a discussion that involves estimating the likelihood that we can deliver a system of some kind in this domain of competence that can produce sufficient cashflow, soon enough. You got me: that’s an estimate!

Right.

I no longer want to argue about this. I will say things that some of you will find surprising. We can debate the merits of these ideas, including where they fit and where they don’t. We will have different ways to solve the same problems, and I enjoy gathering more tools for my toolbox, so please share your tricks with me. I will sometimes use the banner of #NoEstimates for these discussions, because a market has formed around that name, and I’d like to reach those people. If you try to engage me in an argument about the meaning of “no” and the meaning of “estimates”, then I intend simply to walk away, so please don’t do it. Yes, the name #NoEstimates creates problems, but I’ve chosen to bet that it’ll help more than it hurts. Only time will tell.

References

Patrick Lencioni, The Three Signs of a Miserable Job. Ironically, holding people to their estimates seems like it should promote the aspects of a rewarding job, by Lencioni’s model, but by setting up a game that programmers can’t win, it does the opposite.

Geoffrey Moore, Crossing the Chasm. Whether you agree with the model or don’t, the language of “innovators”, “early adopters”, “late adopters”, “late majority”, “laggards” continues to pervade our discussions about how products and ideas spread through the market.

Doug Rosenberg and Matt Stephens, Extreme Programming Refactored: The Case Against XP. I have not read this book and I never plan to read it. You might find it interesting, but I strongly disliked the authors’ style of communication and stopped listening to them as a result. In spite of this, people whose work I respect (like Steve McConnell) have written good things about this book, so if you read it, then I hope it helps you.

J. B. Rainsberger, “Why I Try to Communicate in E-Prime”. I like tricks like this one, and with it I have transformed the way I relate to people. Seriously.

“Don’t Let Miscommunication Spiral Out of Control”. It seems that the miscommunication about #NoEstimates has started spiraling out of control, and I think that the concept in this article can help us.

“Practical Tools for Playing Well With Others”. video, slides. Alternative content formats that contains the same concepts as “Don’t Let Miscommunication Spiral Out of Control”.

  1. Here, I use these two terms understanding and interpretation in the sense of the Satir Interaction Model. If you don’t know this model, then I recommend a tutorial. For a quick start, you can glean the model from these presentation slides. If that doesn’t explain enough for you, then I give you two options. If you want my more recent understanding of the topic, then watch “Practical Tools for Playing Well with Others” (49 minutes) from Øredev 2013. If you’d much rather read an article and don’t mind older content, then I offer you, “Don’t Let Miscommunication Spiral Out of Control”.↩︎

  2. Here I’ve pointed out a large source of these problems: labeling language. As soon as we want to label our ideas “good”, “bad”, “right”, “wrong”, we create problems for ourselves. I’ve taken steps to alleviate the problem in my life, and it has really helped me fight less with people. Find out how by reading my article, “Why I Try to Communicate in E-Prime”.↩︎