Arnt Gulbrandsen
About meAbout this blog

Rhetoric in software development

Or: Leveraging Schopenhauer's book of dirty tricks in agile software development.

This rather lengthy posting started when I read Schopenhauer's little book about rhetoric. The book is great, I particularly like the smoothly satirical preface. He describes about forty dirty tricks, and as I read I realised that I've heard every single trick in scrum meetings etc. I think some of my past colleagues would nod as they read Schopenhauer's preface: Nobody absolutely knows yet, but later, with the benefit of hindsight it may become clear that I was right today, so it's best for everyone if I have my way in this meeting.


Rhetoric (/ˈrɛtərɪk/) is the art of persuasion is Wikipedia's first sentence on the subject. When people use the word, they often don't use it to mean exactly that, though. Sometimes it means an argument or an opinionated statement, sometimes a choice of phrasing, sometimes wording with more elegance than substance, and quite often the word rhetoric is used to mean any device that's used to win a discussion except by achieving a shared understanding of the subject matter.

That isn't what Aristotle had in mind. I don't think Aristotle ever used dirty tricks such as the door in the face, the Gish gallop, guilt by association, or making jokes about other participants in a discussion.

Books on rhetoric study, analyse, categorise and explain rhetorical devices, which are means to persuade, or if not persuade, at least to carry a meeting. Today I want to speechify a bit about using the same field of study, these same devices, in three other ways: ⓐ Listening more attentively to what others are saying, noticing unfair rhetoric, ⓑ countering or neutering that unfair rhetoric, and ⓒ staying fair.

Below you'll find Schopenhauer's dirty rhetorical tricks, grouped and worded as I see it. I describe each (fairly or unfairly), mention an agile software example to help you learn to notice it when someone uses that dirty trick, and if I can, I write a bit about how to counter that trick while staying fair and within a normal software development context.

If you'd rather read the original, Schopenhauer's full text is available from Project Gutenberg and you can also get inexpensive printed editions. That text was actually glued together after Schopenhauer's death from bits and pieces the great man wrote. I think it represents his opinions fairly, but it's clear that he chose not to publish it.


Wilful misunderstanding. Setting up a strawman. Schopenhauer starts with three variants of this device. The first is acting as if a statement were more general (covering more cases), the second as if a word meant something else, the third as if a statement were stronger (admiting fewer/no exceptions).

Doing [description] would solve the majority/most important/… of cases. That won't solve [case]. The responder may be innocent, or may wilfully confuse most with all, and point out that all is wrong.

I don't know any reliable way to neuter this. Sometimes it helps to point out a critical difference between what's said and what's misunderstood, e.g. if we want to solve all cases, not just most, [blah] will be terribly expensive, or do we even want to spend the necessary effort to solve all cases, not just the majority/the most important?. If one can think of a critical difference.

Sneaking in unjustified work by making unobjectionable suggestions, then combining them (Schopenhauper's device 4). I saw this for IPv6 support, which one developer wanted, and got by making a trivial unit test and then suggesting that a new feature should be shipped only when all tests passed (without mentioning that test). Management wanted the new feature, implementing the new feature required either deleting the test or writing much IPv6-related code, deleting unit tests wasn't permitted.

Knowing the codebase very well helps, as do innocuous questions like do you know anything that would complicate this?.

Invented rationales (device 5) can justify anything, or at least anything that's small enough that noone goes off to check. [Customer] demands [thing], so we have to do [related thing].

I've no idea how to neuter such things. One has to trust people; not trusting people is also unfair, even if it's not on Schopenhauer's list.

Misusing equivalent phrases (6), often by pretending that two partial synonyms always are synonyms.

For example, a code/testing regime may be agreed by everyone, but the only code that was mentioned in the discussion was that which is shipped to customers. Then later, someone says that this code style is required for all code, including in-house tests and CI/CD scaffolding, and argues that this was decided by referring to the discussion that covered code shipped to customers.

When that happened I argued that requiring the same standard of in-house code as code shipped to customer was inappropriate, because it valued a bug that inconvenienced customers no higher than a bug that inconvenienced one developer. I lost. I've also tried to point out the difference in meaning, but that just sounded like hair-splitting for its own sake.

Talking at length, then pretending to have argued (7) is nasty. Schopenhauer says roughly: Ask friendly questions and talk about the other alternative and its potential problems until people forget the start, then quickly act as though your preferred alternative has no potential problems.

One of my managers once asked questions about a suggestion of mine until everyone's ears was full of possible disadvantages, and noone remembered the possible advantages of what I had suggested. My idea seemed bad, of course, and was shelved. We did nothing, with terrible results, and I still feel vaguely guilty.

Taking notes and drawing little tables helps, then you can look at your filofax and say, we've talked a lot about A's problems and B's advantages, but we haven't really talked about B's problems or compared the problems and the ink on your paper lends your statement authority.

Making your opponent angry (8) and then winning by being professionally calm, independent of the merits of your proposal.

I don't want to go into this. I've always been passionate. A performance review of me once said manic-compulsive focus on shipping and users. That's a true description, and it's something to be ashamed as well as proud of, so I don't want to go into this.

Obfuscating discussion by choosing an unnatural order (9) is something I've seen among others, but not participated in as far as I can remember. For example I sat silently in a discussion where one course of action would raise costs, the other would reduce income. One participant started by suggesting that costs should absolutely not be raised, and got that decided. The natural order would be to estimate the cost increase and the income reduction, compare them, and then decide.

I think that today, I would have suggested that someone do a time-boxed cost evaluation, we have decided, but it would be good to have some estimate of both costs anyway.

Point 10 is an outlier; it assumes dishonest behaviour from everyone. I've seen that (in Scrum meetings, yes) but this posting assumes that you want to stay fair, so I ignore point 10.

Discussing single instances and assuming something general (11) sounds more complicated than it is. People do it, e.g. by first getting agreement that Amazon's S3 is a great datastore and then that AWS t3.nano instances are cheap enough to ignore the price, then later acting as though what has been agreed is to use all of the hundred-plus AWS services for everything.

Depressing.

Choose flattering names (12) or the opposite, depending on whether you want people to like the thing named. Someone who wants to rewrite a system says legacy, someone who doesn't says stable.

Describing a horrible opposite (13) is a neighbour of point 12. Someone who doesn't want to rewrite that system says remember that rewriting Netscape took several years and the lack of incremental updates practically doomed the company. The several years works, even though Netscape actually was tens of times as big as the project being discussed, and the period without updates would be months.

Simply pretending (14) works for some people. As we've decided when no such thing has been decided. Schopenhauper connects this to several of the other points above, but considers it a technique of its own, and suggests that one needs a good voice and plenty of brazen insolence to carry it out.

A past colleague used this about code style; noone bothered to look up the code style specification, so whatever he said was in effect our code style. (Which wasn't very different from the specified style, to be fair, and it wasn't a bad code style either. But I don't think he ever looked it up either, he just said whatever he wanted.)

Taking notes helps. We decided what? I don't have that in my notes? When did we agree on that? Looking at old documents helps, keeping an organised wiki helps.

Stating something similar, but crucially different (15) means, for example, that someone uses one of those great old quotations, perhaps by Dijkstra or Knuth. But the actual issue at hand is not what Dijkstra or Knuth discussed. Premature optimisation is the root of all evil, perhaps, which Knuth said about writing code, and which does not apply when choosing platform for some code that is to be written.

Schopenhauer then says: If the others accept the statement, fine, pretend that they've accepted the thing you really want. If the others note the crucial difference, use RAA to show that the statement is very bad, and pretend that since this statement is wrong, what you want is right. And then Schopenhauer concludes, with a tinge of sadness: There are people who do all of this instinctively.

All I can suggest is to ask about the crucial difference. Do you mean to say [this] or [that]?

I like to ask questions. People with strong opinions sometimes become more factual when they talk about backgrounds and reasons and rationales, and that always improves the discussion, if it happens.

Inventing a contradiction (16) between what's said now and some earlier statement. Didn't you agree last week that premature optimisation, etc?

I have answered that yes, so I did, and I don't think that applies in this context and programming is complicated, but not necessarily explaining why this case is different. I might. If we wait with optimising this until we know we need it, the site will be down while we do it, perhaps. Or I might not, if I thought it likely to be a digression.

Defense through subtle distinction (17), such as when someone wanted to use Motif for an application and someone else countered that comparable Motif applications were unusably slow on the target hardware, and the suggester explained that ah, but those were written by people who didn't know Motif, whereas my suggestion is to award the contract to professionals who do know Motif. (Note: I'm not sure I was present at that meeting. The same person said the same thing in several contexts, and I heard him at least once, but I'm not sure which.)

Defense through digression (18) is when someone realises that a counterargument is about to foil their proposal, and interrupts to prevent the argument from being spoken. maybe we should hear someone else's opinion or I think we've spent enough time on this point, for example.

Escaping to generic blah-blah (19) means, for example, that someone responds to measurements or data by arguing that measurements are difficult and/or uncertain in general, never saying anything specific about the accuracy or reliability of this measurement but imputing that since measurements are imprecise or difficult to perform, this one should be ignored.

I've experienced this many times and have no counter. Reflecting on it now, I think I may have made too many tables and not enough graphs, though. Presenting the data as lucid graphs might have prevented the escapes. Maybe?

Draw conclusions yourself (20) is another variant of a not-quite-supported conclusion.

If people agree on some things, then it's possible to say something like well, since A and B and C, it's clear that X will be our best option, and it's difficult for most participants to remember that A, B and C aren't the only factors that matter for whether X is better than Y. The trick works because the person who wants X chooses the phrasing and distracts the other participants from remembering factors other than A, B and C. If another person were to draw the conclusion, the other factors might not be so easily forgotten.


At that point I had written for hours and my example for point 20 was painful. As an example it was great, remembering it was painful. I stopped writing and never resumed.

I deleted that now, and post it with the first 19½. It's more than long enough as it is.

Rereading it, I notice that the counters I describe above share some traits. Many of them assume that most people want to make the best decision on a factual basis, and that the dirty trick can only be effective when it's hidden.

Some of them use some trick to negate spoken emphasis, such as using the authority of paper to win over long spoken sentences. That is admittedly a trick, but fair so long as the ink on the paper is fair and honest.

Another thing I remember is the day when I started reading the book. It was a beautiful summer day in Italy, the children were playing in a pool while I read, my wife complained that I was too lax and they'd get a sunburn, and then we had an espresso and a piece of crostata. Life is good, sunburn aside, rhetoric aside.