What does it mean to be a good Christian? How do you decide whether something someone made is art or not art? If you say you’re practicing Agile software development, and I say you’re not – that you’re missing the point – where do we go from there?
The answer to the last question, in my experience, is: nowhere, and fast. But we don’t have that problem with questions like “is that tree an elm?” or “is light a particle or a wave?” Why not?
I recently stumbled across a paper that tries to answer that question. Since I’m exploring using a Zettelkasten method for writing nonfiction narratives, I thought it’d be useful to turn the notes I took on it into a blog post.
What’s in this for you? Understanding “essentially contested concepts” might save you some time that would otherwise be spent fruitlessly – or alert you to a different way to learn what you think.
The paper is “Essentially Contestable Concepts,” by W. B. Gallie, from 1956. There’s also a Wikipedia article, but I don’t like it much.
I should warn you that this is my elaboration of Gallie’s idea, infected by my own particular quirks and beliefs. I don’t think an expert would think I’m wildly wrong, though.
Concepts with value
People have been arguing about what characterizes a good Christian for over 2000 years, and there’s still widespread disagreement. In comparison, the question of whether light is best described as a particle or a wave has been settled, and quite speedily (relatively speaking).
The reason is that light wouldn’t be a better thing if it were a particle instead of a wave (or vice versa). And only a vanishingly few people would think saying “Um, that’s actually an elm, not an oak” is intended to make them think worse of the poor tree.
That’s very much not the case for statements like “she’s not a real Christian” or “you call that art?” Essentially contested concepts are strongly tied up with ideas of value. If something fits within the concept, it’s good. If it doesn’t, it’s bad.
To repeat the philosopher Richard Rorty: Contingency, Irony, and Solidarity, p. 73
All human beings carry about a set of words which they employ to justify their actions, their beliefs, and their lives. These are the words in which we formulate praise of our friends and contempt for our enemies, our long-term projects, our deepest self-doubts and our highest hopes.
Rorty referred to that set of words as a person’s final vocabulary – not, I have to say, the greatest coinage ever.
Essentially contested concepts aren’t, analytically, exactly the same concept as a final vocabulary (I don’t think), but there’s a lot of overlap, especially the centrality of value or emotional reaction. Even something as inconsequential as the way you do software development is freighted with value. You can see that from the very word “Agile”: of course my team is Agile. What’s alternative? We’re torpid? I’m not saying that associating an approach to a word with positive connotations is what makes “being Agile” a term of praise. I’m saying the pre-existing opinion that such approaches are good made it natural to label them with a word like “agile,” especially since the previous jargon was “lightweight methods,” and “lightweight” (at least in American English) signals disapproval.
Concepts with history
Gallie’s origin story for an essentially contested concept starts with exemplars or foundational examples. For Christianity, the most important exemplars are Jesus, as described in the Gospels, and the apostles, perhaps especially as described in Acts. No one would say that Christ behaved in an unchristian way. Moreover, when faced with a moral problem, “What would Jesus do?” is an entirely normal approach to solving it.
Similarly, when discussing whether a piece of music is art or not, reference will be made to characteristics of pieces (most) everyone agrees are exemplary: “you can see this piece is in a tradition dating back to Haydn and his innovations in the classical style.”
Agile, as a concept, was also built from exemplars. The Chrysler Comprehensive Compensation System was that for Extreme Programming (and Agile in general). Ken Schwaber used his first Scrum project as an exemplar in his training. In my own consulting, I told stories of how the “Scrum master” and product owner for a particular Scrum team acted.
But concepts don’t remain stable. The associated approaches, problem-solving techniques, and ways of thinking change over time as the concept is applied to new circumstances. What it meant to be a Christian changed as the faith moved from being a Jewish splinter group to the state religion of a mighty empire. Jesus and the Apostles didn’t face the question of what it means for the leader of a Roman army to be Christlike. The Apostle Paul didn’t need to invent Just War theory because he wasn’t personally faced with reconciling “thou shalt not kill” or “Prince of Peace” to inevitable civilian deaths.
And “Agile” weathered the shift from custom in-house apps to shrink-wrap software and web deployment without (we thought) changing in a fundamental way – just as my father’s understanding of the concept “hammer” didn’t change as the handles shifted from smooth wood to plastic with an especially grippy surface.
Parts
So far, essentially contested concepts don’t seem much different from any old concepts. My sense is that tying concepts to exemplars was somewhat unusual in 1956, but it’s pretty commonplace today. It’s called prototype theory, which originated with Eleanor Rosch around 1971. Two semi-popularizations are Women, Fire, and Dangerous Things (1987) and the whimsically titled Big Book of Concepts (2002). Here’s an example of prototype theory: when I was growing up, Playboy publisher Hugh Hefner presented as the prototypical bachelor, and his characteristics (very into high-fidelity stereos and jazz, etc.) were those of the prototypical bachelor. Before Hefner, the prototype was different. Some time after him, it seemed to become the typical reader of Maxim magazine (which I am surprised to find still exists). I have no idea who the prototypical bachelor is now. One possible difference between prototype theory and what Gaille describes is that his concepts are described as being derived from prototypes, whereas the “bachelor” example shows that concepts have prototypes, ones that can change while the concept stays stable (enough).
Gaille zeroes in on a key property of the essentially contested concept: it has structure, it contains parts. Consider Agile. It almost definitionally has four parts, four values:
[W]e have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Christianity has its parts, too. There’s the red-letter parts of the Gospels (Jesus' quoted words), perhaps especially the Sermon on the Mount. There’s the Book of Revelation. There’s the Apostle Paul’s letters explaining doctrine to far-flung congregations. There are parts of the Old Testament that have been retained, and others that have been superseded. And so on.
The key thing about the parts is that different people emphasize different parts. That doesn’t mean they reject some of the parts: they just don’t pay as much attention to them.
-
When Martin Luther translated the Bible into the vernacular, he was pretty dubious about the value of the Book of Revelation. Modern Protestant US evangelicals give it much, much more weight, frequently treating it as advice for navigating the near future.
-
There’s been a long debate within Christianity about whether people should pay more attention to Paul (“For we maintain that a man is justified by faith apart from works of the law”) or James (“So too, faith by itself, if it does not result in action, is dead”).
-
Was Jesus a woke soy boy (Sermon on the Mount) or a manly avenger (Revelation, killing a fig tree, the moneychangers in the temple, in the lineage of David)?
-
Was Christ primarily a fulfillment of the Old Testament or did He primarily represent a New Covenant?
-
Both the Old and New Testament have a lot to say about supporting the poor and mostly negative things to say about the rich. But there are passages that suggest faith will be rewarded here on earth, not just in the afterlife, which is appealing to those not thrilled with the verse “go, sell your possessions, and give the money to the poor, and you will have treasure in heaven.”
The important thing here is that choosing one side of a controversy doesn’t reject the other side. A Paulite doesn’t deny the book of James, but rather feels that Paul is more essential to Christianity, so the people who disagree are missing something they oughtn’t.
Agile has had a similar (though less consequential!) dynamic. As a consultant, I found that teams who resonated most to “individuals and interactions” were quite different from those focused on “working software.” I’d say the latter teams were generally more Agile, but that’s because I share their priorities. Individuals and interactions matter, but (in the words of someone who didn’t want to be cited) “sooner or later, at the end of the day, someone has to sit down and write some damn code.”
Moreover, I’ve seen a perhaps-subtle but important difference between teams that interpreted “Customer collaboration” as directed toward end users (outside the company) vs. toward company management. I’d say early Agilists tended to be people with something of a “problem with authority,“ Weirdly, given how things have turned out, early Scrum was much more aggressive toward management than, say, Extreme Programming. coupled with something of a protective attitude toward the users. Being “relentlessly focused on business value” was something of a later development (an evolution of the concept of Agile) that I personally felt became overemphasized. (And it’s become especially awkward in this age of enshittification, where business value tends to be actively opposed to end user value.)
Are you bristling a little at my implication that teams nowadays let “the suits” push them around? Well… welcome to the world of the essentially contested concept.
But more importantly, notice that we both (probably) agree on two principles:
-
We should be responsible for what our work does for (or to) our customers.
-
We’re being paid to produce value for the business, not code.
What differs is where we place our emphasis. That means:
-
Arguments about whether a particular team is Agile, or a particular person is a Christian, come down to arguing about who’s got the right emphasis (even if we often don’t realize that’s what we’re arguing about – always a recipe for a productive conversation).
-
So arguments about essentially contested concepts have the form “of course you should care about both A and B, but you should care about B more than A.” That’s a hard argument to make because we’re talking about preferences. People don’t adopt preferences because they were reasoned into them, and it’s hard to reason someone out of a position they weren’t reasoned into.
-
Especially if those preferences are themselves a final vocabulary or an essentially contested concept. My favoring the end user is tied to a fundamental belief that you should take the side of the person with less power. My disfavoring of management is because of my vaguely anarchist belief that relations of domination – “you have to do this because I tell you so” – are typically unjust. That led me to describe Agile as being, importantly, “team-scale anarcho-syndicalism.” That resonated with at least some prominent early Agilists.
But people can change
The dominant understanding of how scientists make decisions is “falsifiability”: you should provisionally believe in a scientific theory so long as it survives experimental tests. In a slogan: a theory can never be proven, but it can be disproven. The wikipedia description. Falsifiability is primarily due to Karl Popper and his Logic of Scientific Discovery. His description is more subtle than I’ve presented it, but still (I think) wrong for the reasons given below.
The philosopher of science Imre Lakatos observed that real scientists don’t behave like that. For example, the Astronomer Royal of Britain regretfully informed Isaac Newton that his new theory of gravitation was inconsistent with the measured movement of the moon. Refutation!
However, Newton failed to abandon his theory. Instead, he invented a new theory – of optics – and told the Astronomer Royale that if he used the new theory to adjust previously-recorded observations, he’d see that the adjusted numbers would match Newton’s earlier theory.
It turns out the numbers were closer, but still off. I don’t know if that was known in Newton’s time. The point is that, when it did become known, no one did anything about it. The puzzle remained, mostly ignored, until it was discovered that the moon’s center of mass is offset from its geometrical center, which explained the discrepancy.
Lakatos observed that it’s pretty rich to be saying that Isaac Newton wasn’t doing science right. I described Lakatos' ideas in an ancient blog post, “Imre Lakatos and Persuasion.” The main text is his The Methodology of Scientific Research Programmes. There’s a concise and good description in For and Against Method.
It turns out that scientists adopt new ideas not because of a lack of refutation, but because of the presence of an impressive (“novel”) confirmation. In the case of gravitation, the doubters conceded when Edmund Halley predicted the return of the comet that now bears his name to a previously-inconceivable degree of precision.
I believe that a pleasurable surprise at seeing something put to effective use motivates more than just scientists.
Anecdote: once I was consulting for a financial services firm. The team was having a meeting wrestling with some questions about how a new feature for some internal software should behave. The meeting was going nowhere, slowly, when I suddenly said something like, “Wait. The users of this software are sitting, what? 100 feet? 200 feet? – from where we are right now. Why don’t we just ask them?”
We did. It turned out what the users actually would be happy with was way simpler than what the team had been planning to deliver. The old design was scrapped, a fun design session happened, and everyone left happy.
Two observations:
-
I demonstrated the practical value of emphasizing the end user in one’s thinking, and I like to think that shifted the team’s understanding of Agile in my direction. All without argumentation.
-
It was because of what “parts” of Agile I consider more important that I reflexively looked to the user when solving problems. So, while I’m more of a “working software” guy, I used a particular bias to spark the right kind of interaction with the right individuals.
Yay me! (I omit the story of when proposing a more ambitious version of the same idea got me abruptly ejected from a consulting gig. That was less fun.)
Should we stop arguing?
Gallie says not. (You were expecting a philosopher to come out against argumentation?)
When I argue with you about Agile, or Christianity, or Art, my goal may be to convince you, but the practical effect is to help me zero in on the parts of the concept, to understand them better, and to learn how to put them to better use in my own activities. If I’m alerted to how important serving the user is to me, I’ll figure out how to do it better.
Gaille has other observations about argumentation. I find them less convincing, so I’ll let you read his paper for yourself.
The stirring conclusion
I don’t know that I have one. Maybe I can offer the same advice people give to writers: show, don’t tell. Instead of decreeing that someone else is or isn’t a Christian, concentrate on being visibly Christian yourself, according to your own understanding. If people see you as someone worthy of emulation, they’ll adjust their own (possibly tacit) understanding of that essentially contested concept.