Nicolas314

All my geeky stuff ends up here. Mostly Unix-related

Daily Fallacies

leave a comment »

To the question: “Why do we do things this way?“, you often get three different kinds of answer:

Argument by Longevity
“Because we have always done things this way”, also known as “It is known.”
Argument by Numbers
“Because everybody does it this way, there must be a reason.”
Argument by Authority
“Because the experts say it must be done so.”

These arguments are examples of fallacies. A large number of examples and counter-examples are provided on the Wikipedia page, I will merely provide some here:

  • Longevity: Humanity has survived 100,000 years without need for toothbrush, therefore toothbrushes are useless for human existence.
  • Numbers: Most people believe that if you toss a coin 10 times and heads come out 10 times, the next time you toss the coin it has less chances of coming up with heads. Therefore it must be true.
  • Authority: My favourite singer votes for candidate X, therefore I will vote for candidate X.

A fallacy derives from the fact that there is no link between the premises, leading to a wrongly acquired conclusion. A statistical fact is independant from belief, it is a mathematical truth that can be demonstrated. Adding more people or time to the fact does not influence the demonstration in any way. Somebody claiming to be a math expert declaring that the 11th toss has different than 50/50 chances could easily be proven wrong.

A science experiment on monkeys was apparently carried out in 1967 (Did the monkey banana and water spray experiment ever take place?). The experiment could be summarized as:

Five monkeys were locked in a cage with a banana hanging from the ceiling. Whenever a monkey tried to get the banana they were all sprayed with ice-cold water. After a while they stopped trying. Next step: they replaced one of the monkeys. The newcomer tried to get to the banana but the others would beat him up before he had a chance, knowing perfectly well that touching the banana triggered a cold shower. The researchers kept replacing monkeys one by one until the ones left had never been sprayed with cold water but kept beating up any newcomer who would dare get close to the banana.

The story is often told to illustrate why large organizations tend to cristallize around age-old processes, even when they stopped making sense a while ago. In fact I have seen it happen in nearly every company I have ever visited, no matter how big or small, in a dozen countries in Europe, Africa, and Americas.

Who has never spent a half-hour filling up expense forms for sums largely inferior to what is actually spent in people’s time filling up and processing these forms? Why should it be done otherwise? The rules are the same for one or a thousand euro expense, everybody has always done it this way and nobody ever complained. I know only one company who would pay systematic and fixed lumpsums for travel expenses. You only had to fill forms if you could justify spending more than the allowance.

Argumenting by authority is quite common in the workplace. An example would be external consultants who come up observing for a day or two, go back to their office and end up sending a large report describing how work processes should be changed without giving any other alternative or trying to argument their suggestions. I have seen that happen more times than I am willing to admit.

I do not believe an expert just because he declares himself such. Experts are knowledgeable people so what I expect from them are clear arguments, new data, and demonstrations. I need to follow the same path if I want to end up with the same conclusions. Of course, a talented and biased expert could only provide data pervasive to the point he is trying to make. This is another kind of fallacy and it is pretty hard to detect as soon as things get outside your own fields of expertise.

Fallacies are common, they are everywhere. We all do it because it is easier than a completely logical train of thought that requires mental exercise. They tend to convince people easily, especially when they end up with a correct conclusion. Example: “Most people these days brush their teeth, therefore it is a good thing. Experts will confirm this.”

Yes, dentists will confirm it. And brushing your teeth is definitely good for your health. But you should do it because it has been proven that it helps you keep your real teeth longer and suffer less from cavities, not just because lots of people do it. Proven? Quite a bit: do a bit of search for yourself (hint: use the tubes, Luke), though this will be left as an exercise to the reader.

Coming back to my field of expertise, fallacies in software engineering are a dime a dozen.

  • A large majority of developers can code in Java, therefore my project should be coded in Java.
  • Many programs I use daily are coded in C++, therefore my project should be coded in C++.
  • 95% desktop users are running Windows, therefore I should use Windows
  • CORBA has been designed by a panel of experts, therefore CORBA is an expert-level technology, I should use it in my project.
  • Software is made of lines of code, therefore coding is all that matters in a software project. A programmer’s productivity is measured in the number of lines s/he writes every day.

A closely-related fallacious trait commonly found among young software engineers:

  1. My program crashes
  2. My code is bug-free
  3. Therefore: the environment around my code is faulty

I once coached an intern who told me: “I double-checked my programs and there are no faults, but the binary crashes every time I launch it so the compiler must have introduced bugs in it.” Other young colleagues have found numerous bugs in interpreters, libraries, the operating system, and when all else fails: blame the incompetent user. Yep, all these things can have bugs, but maybe you should first look into the most recent element added to the system, i.e. your own code, before looking into other directions.

Not a day goes by without meeting a young engineer who lectures me about software engineering, usually answering my “why do you do it this way?” by “this is the way we have always done software here”. I am ready to accept any kind of debatable argument but not the longevity fallacy coming from people who have not defined the rules themselves. If things have always happened this way, what was the reason for it initially? Is it still valid today? Are we in the same context now? Why can’t we touch the frigging banana?

The only lesson I got from this over time is: pick the banana, always. Best scenario: you now have a banana. Worst-case scenario: now you know exactly why nobody touched it, even though nobody could explain it to you before.

Advertisements

Written by nicolas314

Wednesday 26 October 2011 at 11:12 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: