Nonviolent Programming
Nonviolent Programming
The idea of Linguistic Relativity has been around since at least the Eighteenth Century. Many folks may have heard of the (misnomerous) Sapir-Whorf Hypothesis.
In a nutshell, Linguistic Relativity suggests that language influences the way we humans think. ‘Whorfianism of the third kind’ proposes that language is ‘a key to culture’.
Setting aside the Rightshifting implications of this for now, I’ve been considering the implications of Linguistic Relativity from the perspective of the humble programmer (a.k.a. coder), especially in the light of Donald Knuth’s description of the job of programming:
“Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.”
~ Donald Knuth
Most programming involves the imperative style. Defining instructions to the computer to tell it what to do. If this, then that. Do this. Do that some number of times.
Actually, I’m surprised there is, as yet, no programming language called “Jackal”. (Although, for the record, there is a ‘compiler-driven distributed shared memory implementation of the Java programming language’ named Jackal).
Does daily immersion in the imperative style of communication, in imperative languages, shape the programmer’s thinking in such a way as to increase the tolerance for command-and-control behaviour? Does such implicit imperativism contribute to the preservation of the status quo in our knowledge-work organisations?
Should We, Could We?
In Rosenberg’s NonViolent Communication, he cautions against the assumptions implicit in the word “should”:
“Avoid ‘shoulding’ on others and yourself!”
~ Marshall Rosenberg
I note with irony the use of the word “should” at the heart of modern BDD, for example. This is but one example of what we might choose to call “rampant imperativism”.
E-Prime
The idea of modifying language to aid thinking is not without precedent. D. David Bourland, Jr. first proposed E-Prime (in my mind, a close cousin of Giraffe language) in order to help people “reduce the possibility of misunderstanding or conflict”.
New Language, New Feelings
Could we conceive of a different style, a different language of BDD, of coding in general, built upon the Four Steps of Nonviolent Communication? What would a Nonviolent Programming language look like, feel like to use? Would there be knock-on advantages to Nonviolent Programming and e.g. Nonviolent BDD?
If Gandhi had been a programmer rather than a lawyer, what might his code have looked like?
Conversely, If he had been immersed in COBOL, FORTRAN or Java for forty-plus hours a week, would he ever have come hold his views on the paramountcy of non-violence?
What implications – seen through the lens of Linguistic Relativity – would adoption of such a language and style have in our communications as individuals? Could forty hours a week of Nonviolent Programming contribute positively to the health and well-being of our human dialogues, our personal interactions and our organisations?
– Bob
Further Reading
Linguistic Relativity ~ Lera Boroditski MIT paper
The Linguistic Relativity Hypothesis – Stanford Encyclopaedia of Philosophy
Think Different
I would also remind folks that in the case of the Tariana natural language there is a reduced possibility of misunderstanding, in that it makes it less likely to confuse opinions with facts. This is because there is no grammatical correct way to report information without expressing how do you know them. i.e. “It’s raining”, is not correct, “It’s _visually_ raining” as like “I’m reporting that I see that it is raining” is correct. http://www.abc.net.au/radionational/programs/linguafranca/telling-the-truth-in-tariana/3406840#transcript
Thanks for the post. Yes, probably we may start looking at non violent programming languages as well.
Tony
I think Prolog was an early first step along that path. It’s such a paradigm shift though – I taught it once and it took weeks for (2nd or 3rd year) students to grok it. When they did though, it was amazing – you could literally see the light bulb go ON!
Oh, so I don’t have to tell the computer what do do any more? I just tell it what I know, how to transform it and what I’d like to know! Your post has got me thinking that the “paradigm shift problem” was very deep, and that’s probably why no one uses it any more. Sad, as with all the processing power and memory capacity we have now it should fly!
Hi again, Bob
> Does daily immersion in the imperative style of communication, in imperative languages, shape the programmer’s thinking in such a way as to increase the tolerance for command-and-control behaviour?
In my experience: definitely! More than once, when I have brought programmers and product people together to discuss (for example) too much scope, or disappointing quality, the (simplified) conversation went something like this…
tech people: … but YOU SAID we had to deliver all that, by (some date) ! It is impossible to reach that date with full scope AND full quality, so we are making (“have to make”) compromises.
[ typically this has been showing up as: fibbing about doneness, dropping features without forewarning, heaps overtime and the subsequent drop in craftsmanship/creativity, delivering broken code that “can be fixed after delivery”…]
product people: well, you should have told us sooner! we always have some room to negotiate with the customer!
[ at this the tech folks fall silent – shocked, incredulous, betrayed, flabbergasted. I think the product people used imperative language to communicate their need (a wish), all the while knowing among themselves that there was still room to adjust. The tech folks heard a need (a command), accepted the assignment to deliver on it, and felt committed and bound (perhaps trapped?) to deliver exactly that, thereafter. ]
Teams that model their interaction with users/product people on a software API can fall into the trap of imagining an instantaneous, hard “contract” where there is in fact the need for something more pliable… a human conversation over time, incorporating new knowledge as it surfaces.
Are these teams “tolerating command and control behaviour?” You know, while this is possible, it seems equally possible to me that they are in fact creating and entrenching it themselves. While this may seem to them a necessary, protective measure (against all the chaotic, non-deterministic dealings in the world of product and customer), it can in fact project a team image of intrangisence, even contrariness. (And some of us have probably seen a team use this legalism to actively bash outside parties).
I think the desire for this shift underlies the Agile Manifesto’s value of “conversation over contract negotiation”, embodied in the XP “card, conversation, confirmation” pattern, TDD, and others. Unfortunately we still see these practises implemented defensively, rather than in the collaborative, emergent spirit of the manifesto.
I am reminded of the book Language and the Pursuit of Happiness, which comes out of the Ontological school of life coaching: http://www.amazon.com/Language-Pursuit-Happiness-Chalmers-Brothers/dp/0974948705 .
Ontological (or: “human”) coaching holds that our language shapes our experience, and that we are at choice about language. I think of it as: our mental models (revealed and re-inforced by our language) can lead us to assume boundaries and rules that make life harder… tho they do not really exist!
An important question for teams that want to be more successful is:
* which rules are real and which have we assumed or made up ourselves?
* how many of the former could be reframed as “guidelines”?
* and: what if we just dropped the latter?
A leader with a coaching stance can help teams choose to “break the rules” in experiments that test and reshape mental models … and hence reshape our work, conversations, relationships… and happiness. Such a leader with a “non-violent” coding language could offer experiments with new mental models, inside the safety of a pair or a team. Hmmm… sounds potentially influential!
deb
http://abiggerga.me
TentativelySuggest.That(actual).MightBe(1);
😉
The “should” in BDD was a response to the imperative style of “assert” or “test”.
Dan (paraphrased) said “If a test reads testDoorIsUnlocked, or assertTrue(door.isUnlocked()); then people will tend to believe that if the test fails and the door is locked, then it’s a problem with the code. If the test reads doorShouldBeUnlocked, it gives the person investigating the failure the flexibility to ask Is this still true? Should it be unlocked?”
Having said that, NLP calls “should” and “must” modal operators of necessity.
May and Suggest are too soft, Should and Must are too hard.. what would you suggest as a middle ground?
@Andy: What about “Expect”? -> “testDoorExpectedToUnlock”
@Corinna Expect has a lot of the same issues. It should be flexible, but it carries an air of the imperative. Parents tell their children “I expect you to behave” which is not really open for negotiation.
Assume would work, and some BDD frameworks use this, but again, there’s a negative association with assumption (Assume makes an ass out of u and me)
My personal view is that should is adequate as long as it comes with education of its meaning within the BDD context
Hi Bob, I’d like to echo Andy’s statement. I get why we avoid “You should…” in communication. I don’t understand the problem with “The computer should…”. I’ve found educating people to use it as a mechanism for uncertainty and question, “Should it?”, helps to spot that uncertainty. We’ve been doing this since at least 2005: http://lizkeogh.com/2005/03/14/the-should-vs-will-debate-or-why-doubt-is-good/
Since you consider it to be “rampant imperativism”, please could you propose a better alternative?
Yes. Exactly. I don’t worry much about dis-empowering the computer by telling it exactly what to do and how to do it, in detail. Computers don’t have independent agency (yet). So that’s just what we have to do. Computers, as they exist now, are designed to do just exactly what we tell them to do. Nothing more. Nothing less.
Further, “should” statements in computing are always negotiable. We’re an industry built on statements on how you “should” design and build software. Books full of them. Many thousands of them. And many are contradictory: I am constantly facing decisions, between “A” and “B”, where one “should” do “A” and not “B” because of one widely accepted rule, and yet you “should” do “B” and not “A” because of another widely accepted rule. So, of course, you should do “C”. But that violates a couple of other rules. And so on. Eventually, as an experienced developer, you must decide which “should rules” carry more “weight” (in terms of likely future effects), and so which should be compromised in favor of the others.
Of course, if someone can come up with a better and more useful verbiage than “should” for use in BDD, I’m sure the community would be happy to hear about it.
Pingback: Programming in Prolog | changearc