Click here to Skip to main content
13,900,891 members
Click here to Skip to main content
Add your own
alternative version

Tagged as



1 bookmarked
Posted 22 Feb 2013
Licenced CPOL

Deductive Reasoning: It's Worth a Second Look

, 22 Feb 2013
Rate this:
Please Sign up or sign in to vote.
Deductive reasoning.

Deductive reasoning is "the process of reasoning from one or more general statements to reach a logically certain conclusion." This concept is the foundation of modern science. Any suggested premise is vetted through deductive reasoning to determine its validity. Deductive reasoning starts with a general hypothesis and builds towards a specific conclusion. It reaches this conclusion through a process of elimination. Deductive reasoning should not be confused with "inductive reasoning." In fact, they are polar opposites. Inductive reasoning builds conclusions through the examination of specific examples. Its success or failure is based on the size of the examples being examined. While both inductive and deductive reasoning have their purpose, inductive reasoning is not supported by the scientific community.

The following puzzle is an excellent example of deductive reasoning:
Three geniuses stand in a single-file line, one behind the other. Each can see only to the front, so the rear person can see the middle and the front, the middle person can see the front, and the genius in the front cannot see anyone. You have five hats. Two are white, and three are red. You blindfold the three geniuses, who are utterly truthful, and put a hat at random on the head of each. Then you hide the other two hats and remove the blindfolds. You then ask each genius to name the color of his hat which he cannot see. The rear one says "I don't know." The middle on says, "I don't know." Then the front one says, "I know." What color is the front genius' hat?

The answer: red

Here's why:
  1. The man in the back can see two hats, but he doesn't know what color his hat is. This means that the two hats are either red/red or red/white. If they were both white, he would know his was red.
  2. The middle man is the key. From the back man, he can deduce the two options, red/red or red/white. He can see only one hat (the one front man's hat). If that hat were white, he would know he was in the red/white combo, and would therefore know that his must be red. But he did not know.
  3. From this, we can deduce that the front man's hat is red.

Puzzle solving aside, what bearing does this have on programming? The ability to properly harness deductive reasoning in the development world is commonly overlooked. Some assume that all individuals naturally have this talent. Unfortunately, this is not true. Although each individual has some level of reasoning skills, deductive reasoning is based on fact. Basic reasoning skills commonly fall under inductive reasoning. Deductive reasoning is something that must be taught, experienced, and practiced. It is by far the best problem solving tool available to a developer.

For simplicity, let's dive into a non-programming example. A user reports a non-functional keyboard. The first step is to validate if the problem is the keyboard or computer. To validate this, obtain a known working keyboard from another computer and swap them (using the same ports). If the good keyboard works on the computer in question, then it had a bad keyboard, right? Not so fast. It's important not to make assumptions. Try the "suspected" keyboard on the known working computer. If it does not function, then the keyboard is bad. If it's functional, then the test is inconsistent and therefore invalid. Too many variables are in play. Seek to eliminate those variables and start over. The same rules apply if the problem was the computer and not the keyboard. That is basic deductive reasoning.

The following are a few tips about problem solving with deductive reasoning:

  • While building a hypothesis, be sure to validate the factual nature of each element. The biggest pitfall of deductive reasoning is conclusions made on invalid data or facts.
  • Validating a factual element may require prior knowledge or additional research. Do not make assumptions.
  • Always compare expected outcomes against a "constant."
  • Isolate testing to one change at a time. Multiple changes can invalidate results. If a test yields inconsistent results, unknown variables are in play. Seek them out.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

You may also be interested in...

Comments and Discussions

QuestionThe non programming was clear and the last paragraph was useful ! Pin
Phani Katakam27-Feb-13 23:35
memberPhani Katakam27-Feb-13 23:35 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web04 | 2.8.190306.1 | Last Updated 22 Feb 2013
Article Copyright 2013 by Zac Gery
Everything else Copyright © CodeProject, 1999-2019
Layout: fixed | fluid