A bit of a screed about naming, triggered by a super idea from Dan Terhorst-North.
In this article, I’ll be centering my remarks around an excellent observation by Dan Terhorst-North @tastapod, brought to my attention by Joshua Kerievsky @JoshuaKerievsky. Dan observes that “Example-Guided Design” might be a really good name for the disciplines variously called TDD, ATDD, and BDD, because they are all centered around examples.
Joshua asked what people thought of the idea, and I replied “I see a pattern”. He asked what I meant, and I said:
The pattern I see is two-fold, really:
- /Often/ there are some new ideas that truly add to, or at least refine, or maybe just draw together, some learnings about the topic; (edited)
- Always a new (and admittedly perhaps better) name for what’s mostly old ideas.
You can find the thread if you’re unlucky. It ends with some sarcasm directed at me, which is, let’s be realistic, carrying coals to Newcastle.
Here, I want to talk a bit about what’s behind my long-standing concern with names and capital letters.
I’ll begin by introducing the players:
Ron Jeffries (your friendly author) is an essentially retired Agile author, coach, and curmudgeon. He is privileged to have been one of the Manifesto authors, and the world has been subjected to his prolific if not sensible writings on the subject for over twenty years now.
Ron does have a company, but it is merely an accounting convenience. It has no employees other than Ron, and no holdings or debt. There’s no reason beyond convenience to keep it going. So he does not directly suffer the concerns that a company owner would suffer.
Ron does not sell anything these days. The only brands he has ever really had were his own name and “Ron and Chet”, which is the informal term for his long-term collaboration with Chet Hendrickson (@chethendrickson). He writes a lot but doesn’t advertise. He has managed to survive, when he was working, by word of mouth.
This is a luxury which most people do not have.
Joshua Kerievsky is a brilliant agilist, and a long-term entrepreneur. His company, Industrial Logic, has long been a source of excellent training materials and coaching, and a harbor for some of the best Agile thinkers and coaches in the business.
Joshua is a passionate supporter of safety in the agile workplace, and in this author’s view, this is the most important of his many contributions to Agile thinking.
Joshua is carefully attendant to the branding of his offerings and his company, and has coined such notions as “Industrial XP” and “Modern Agile”.
Dan Terhorst-North @tastapod of dannorth.net is a consultant and coach of many years, with a strong background in systems thinking, Lean, and Agile ideas. He maintains a strong independent spirit, while collaborating with others as needed to serve his customers.
Dan, it seems to me, always brings a bit of an outsider’s view to Agile, and as such, he tends to come up with slightly different takes on things, often adding important insights.
This “Example-Guided” notion is one of those insights.
I’ll try to do justice to this idea here, and will provide a link to Dan’s own (and better) words if he has a link for me. Meanwhile he has suggested reading Growing Object-Oriented Software, Guided by Tests, by Freeman and Pryce.
Fundamentally, the observation is that all of TDD (Test-Driven Development), ATDD (Acceptance Test Driven Devlopment) and BDD (Behavior Driven Development) begin with concrete examples.
These examples, in all three of TDD, ATDD, and BDD, are expressed as executable assertions in computer code, which exercise the application being developed, and answer back whether the answers in the example match the answers the program is producing.
There are many details in the xDD process, and I believe they are not germane to this discussion. Dan’s observation was that, while the naming ship has sailed, “example-guided” might have been a better name.
I think this is a really good observation, and reviewing my own writings, I can find no cases where I’ve ever referred to the automated tests or checks as “examples”. Had I done so, I suspect my writings would have benefited, and that the readers’ understanding might have improved.
So this is an example of my point number 1:
- Often there are some new ideas that truly add to, or at least refine, or maybe just draw together, some learnings about the topic;
The notion of “example-guided” is a lovely observation on Dan’s part.
There are some issues that I have with the naming of the idea, and they are issues that I always have with the naming of ideas. They are not issues with the idea, nor with the people mentioned here.
New Names for Old Ideas
Let’s begin with the old names, TDD, ATDD, and BDD.
TDD, Test-Driven Development, is the name that Kent Beck gave to a particular approach of writing small “tests”, making them run, and improving the code, back at the beginning of this century. The book is named Test-Driven Development: By Example.
Like hundreds of other people, I’ve picked up this idea, tried to learn it, written about it, given examples of it. I’ve even taught courses around it.
I call it Test-Driven Development because its creator called it that. Unquestionably the tests are little examples of what the program should do.
Acceptance Test Driven Development is exactly like TDD, except that instead of being at a low level in the code, the tests are written at the application level. ATDD brings a new element into the picture: the tests are understandable by what XP calls the Customer and what Scrum calls the Product Owner, the person or people who want the program and know what it has to do.
In TDD, the tests communicate among the developers. In ATDD, the tests communicate between the people with the problem and the people building the solution. ATDD brings a different kind of communication into the picture. Again, unquestionably, although the tests aid understanding between the makers with the need for software and the makers who are writing the code and tests, they are certainly examples.
I will not be able to do justice to BDD here, but I’ll do my best. At the time it was originally propounded, BDD seemed to me to be exactly TDD with new words (behavior) and an associated new test-programming syntax. Since then BDD has grown and evolved, I think, into a more broad discipline, but I remain unable to do it justice. I’ll be happy to revise this section under advice of an expert.
I honestly did not see that BDD brought anything to the table that was substantially different from TDD/ATDD, and it seemed to me at the time that the new name just confused things. That was perhaps short-sighted, but I prefer to think about how things are all the same, rather than how they are all different. In any case, the behaviors in BDD are surely examples as well.
New Descriptions of Old Ideas
I am very much in favor of new descriptions of old ideas. I generally write a new answer to a question, even if I think I’ve written something really marvelous on the topic. I try to express ideas differently every time. I hope that by doing so, I might see a different angle, or might use words that trigger understanding where there was none before.
So I am very much in favor of and excited by describing the example-guided way of looking at xDD. Calling the tests “examples” may well be better than calling them tests or checks. Certainly referring to the test/check/example thing as an example, as well as a test or check, can only help, it seems to me. For example we might well say something like this:
In ATDD, we take an example that we’ve talked about with the Customer, and express it as an executable test. That test, when it runs, checks to see whether the answer we get is the answer we expect.
As this cycle continues, we have a sort of example-guided growth of the product, where the customer and developers together gain confidence that they understand each other and that the product does what is desired and intended.
I just dashed that off, but it seems to me to be a decent example of how all these ideas can be woven together for greater richness and greater understanding.
Honoring the Past
In my work, I claim few if any original creations. I do like to say “I may have invented Story Points, and if I did, I’m sorry now”, but that’s about it.
I think I’ve sometimes done a decent job of building on others’ ideas, and describing how I’ve taken them on board and what I’ve done with them. I try, mostly, to describe what I’m doing, why I think I’m doing it, and what happens. I try to leave it to the reader to decide what to take, if anything, from what I write. If they take “Welp, I’m never gonna do that”, well, that has to be OK with me, even if I was thinking they’d do well to do it. I strive to be understood, not to be obeyed.
And I try to give credit to those from whom I’ve learned, though I am far from as good at that as I’d like to be.
If someone creates a name, I will use it. Beck called it TDD and Test-Driven Development. I use those terms. Joshua calls a recent idea Modern Agile and if I need to refer to it, I’ll use that term.
I do think there is a difference between terms like “Test-Driven Development” and terms like “Modern Agile”, and I’ll return to that later.
New Names Can Cause Confusion
Whenever an existing thing gets a new name, there is some amount of confusion. Sometimes companies bring this on themselves: American Oil Company renamed itself AMOCO and spent millions pushing the new name. I guess they thought it was worth it.
There’s something different, though, about renaming someone else’s idea. If I had started teaching what was essentially TDD and called it the Jeffries Approach to Iterative Development or something, that would clearly be bad, at least by my rather minimal standards.
Now the more different the new version is, the more it deserves a new name.
Mind you, Dan is not proposing renaming xDD to EGD. He’s just musing that, in retrospect, it might have been a better name. And, who knows, it might have. I can readily believe it.
Suppose I had had the “example-guided” idea right after *Test-Driven Development: By Example” came out, and started actively pushing Example-Guided Design. Would that have been OK? Not by my lights. Had I made that observation – mind you, I certainly did not, I was nowhere near clever enough – I might, in my writings about TDD, have used the word “example” a lot and might have said that my work was guided by these examples, and might have drawn some of my stupid pictures showing the examples as hedges and guard rails along the path of development.
If the notion of “example” caught on, everyone might start using it, maybe even Kent himself. That would be cool. Maybe his second edition would have been named Example-Guided Design Using Tests. We’ll never know.
So I think it matters how we use names.
And as far as I can tell, so does Dan: he remarked, probably correctly, that in retrospect it seems like maybe a better name. He has not gone further than that, has not proposed a name change.
I remain concerned about names. Let’s drill into names.
Dan himself, in a long and reasoned Twitter thread, said:
Title Case is a signifier. It says to the uninformed reader that this is a Standard Name. Using that name with other people should elicit the same ideas in their head. It’s not unlike the way @martinfowler describes pattern names: they bring the pattern to mind if you know it.
He goes on to discuss whether I am or am not brand-agnostic. I’m not, but I am pretty sure that the only brand where I’m the first person to come to mind is “Ron Jeffries”, and since my son Ron is a famous brewer, I might be coming in second there. There’s also the “Ron and Chet” brand, with which I’m in the top two people you think of.
But if you think about “Agile” or “Scrum” or “TDD”, my name might come up on a list of asociated names, but I’m quite sure people don’t think of me first. As I put it in the thread:
I support Agile. I explain Scrum. I drive BMW. I listen to Homepod.
But I digress. Dan’s point and mine are much the same here: capital letters signify that the thing capitalized is a thing, a “standard name” as Dan put it.
And it’s a thing that is implicitly different from things with similar but different names.
The name “Example-Guided Design” suggests something different from “Test-Driven Design”, and if you didn’t guess that right away, mentioning them in a few nearby paragraphs will make sure you know they’re Not The Same.
Disciplined Agile is clearly different from Agile. Can you guess how?
Modern Agile is clearly different from Agile. Can you guess how?
“I knew you could.” – Fred Rogers
Do you see a difference between the following three paragraphs?
I do a sort of example-guided design in my work.
I do a sort of example-guided design in my work.
I do a sort of Example-Guided Design in my work.
I see a difference, roughly this:
Here’s a thing I do. My work is kind of guided by examples.
I do something like the thing people refer to as example-guided design.
I do something like the thing whose official name is “Example-Guided Design”.
Now this isn’t cut and dried by any means. But these are, in my view, the general connotations of plain text, italicized text, and Title-Cased Text. You can feel it right there, can’t you?
Brands are often expressed in Title Case, but they’re a bit different.
A business needs to differentiate its offering from the offering of the competitors. A bunch of companies selling “Agile” or “TDD” need something to distinguish them. This can be done in a lot of ways. Sometimes the company is named with the magic word right in its name. “Scaled Agile” is an example. Jumped right on the old bandwagon there, didn’t they?
More commonly, the company has a historical name that it retains, such as Smith Enterprises, and has product or service offerings with more meaningful names associated with the topic of interest.
You might promote a method called “RAPID Agile”. Or you might have an offering called “Expert Agile Coaching”, or “Agile Technical Training”. Now, to me, the first of these is a far better brand, especially if you were to slap a bit of a “TM” on it. Anyone could claim to offer expert Agile coaching, but with a bit of name protection no one else could offer “RAPID Agile” unless you licensed them to do it.
That could be a good business approach. And it would trouble me. It suggests that Agile is not rapid, and that RAPID Agile fixes that flaw. And I don’t like that connotation.
We might have an apple, a juicy apple, a yellow apple. We might have a Fuji Apple or a Red Delicious Apple. There’s a difference.
“Agile” is an idea that was intentionally set free by the authors of the Agile Manifesto, and, to me, slapping an adjective on it and then treating it as someone’s brand troubles me. It’s especially troubling when it undermines an original or equally good notion. It’s even more troubling, to me, if I feel the branding party has done it on purpose. Like if they’ve done it more than once.
That is not the case with “Example-Guided Design”, as far as I know. So I am only somewhat troubled, not deeply troubled.
In distinguishing one’s own offering from other similar offerings, one justly desires to show how one’s own is better. It’s tempting to draw comparisons. But there is, in my view, rather a slippery slope.
It’s one thing for Volvo to focus its development and advertising on safety. It would be another thing to call their product The Safe Automobile. That suggests that all other automobiles are not safe.
So a name like “Business Agile” would trouble me, since the whole point of “Agile” was to bring together business and development and focus development on providing what the business needs.
A name like New Agile suggests that Agile is somehow in need of an update and that you shouldn’t pay attention to that old stuff any more.
And so on.
It’s a bit the same with a Title-Cased name like Example-Guided Design, when it’s placed on the table with, say, Test-Driven Design, or the like. It suggests that it’s the latest and greatest thing and these other things are ancient and no longer relevant. Now if the thing is really brand new, unrelated to the older terms, and not based on the older ideas, then go for it.
The more strongly related it is, the less I’m OK with using the name in a fashion that might eclipse the classic names.
I emphasize again: Dan is not trying to eclipse the old names. It remains open whether his Title-Cased usage, or even my italicized usage will eclipse the old names, and whether it will happen in a good way, or a harmful way.
It’s a concern that I have, a personal hangup if you will. But it is, I believe, a slippery slope.
We really do need to differentiate our ideas and offerings and companies from other people’s ideas, offering, and companies. There really is competition in the marketplace (even though the marketplace is probably only one percent served at present), and in order to bring our good ideas to the people who need them, we need to make them visible and appealing. We really do need to stand out.
But … if the names we choose serve to make other good ideas seem bad, I personally find it troubling, and I often choose to call it out. If the penalty for that is that people write my name in lower case, or prefix it with another word, well, that’s OK with me.
When the Agile Manifesto was created, most of the authors were independent consultants or contractors, and there wasn’t much competition. That changed, with a recession and with the popularity of “Agile”, and with people getting excited and engaging in learning and helping others learn.
And with that came the need for branding and differentiating our products one from the other. That’s how it works. And, in my view, that differentiation can be done elegantly and fairly, and still effectively, or it can be done inelegantly and unfairly.
I prefer elegantly and fairly.
I’ve always been too idealistic for my own good, and it has only been through great good fortune that I’ve not only survived but somewhat thrived. So my view on this is idealistic, I freely grant.
And because I am independent, and because I am essentially retired, and because, frankly, my dear, I don’t give a damn, I will continue to rail against the creation of names that mask other valued names, and the creation of product names that imply that other perfectly decent products are inferior, and the like.
So when I say “I see a pattern”, don’t ask me what I mean unless you want to hear the answer.
Joshua Kerievsky has justly praised Dan Terhorst-North’s lovely description of test-driven ideas as “example-guided”.
Dan appears to have nothing but the best of will in referring to his excellent clarifying idea as “Example-Guided Design”.
I remain concerned about renaming newish things on top of earlier very similar ideas.
I remain even more concerned about choices of name that seem to denigrate or downgrade the old names. This is not the case here.
Get off my lawn.