Fallacy of the Excluded Middle

I spent a lot of time with arguments; mostly reading others', frequently discussing them with coworkers, and periodically posting my own. Closures, statics, inner classes, design patterns... little bits of evidence are sprinkled around the Internet, and I enjoy tracking them down, compiling them, and merging them with others. If I consider enough arguments for or against a topic, say inner classes or statics, and I work to gain experience in that area, eventually I can abstract out a general rule or perhaps some design paradigms to follow. I sometimes call this "insight", or sometimes just say "learning".

After reading so many articles about software, have you ever stepped back from the facts and opinions presented and instead studied how an author argues a point?

Which leads to another meta-question: can you reject an author's thesis based on how it is argued, while completely ignoring the facts presented?

Consider "P ∨ ¬P". This is one way to argue a point. “P” is a premise, a statement, a conjecture. Closure complexity will ruin Java. The static keyword makes testing impossible. Inner classes overload the charter of the enclosing class. “¬P” means not-P. Closures complexity will not ruin Java. The static keyword does not make testing impossible. Inner classes do not overload the charter of the enclosing class. And the “∨” is just or. So "P ∨ ¬P" means P or not-P, that some statement is either true or not true. This is the law of the excluded middle and traces back to Aristotle.

This is how I argue against socialized medicine. “Do we want the people in charge of Hurricane Katrina or the Walter Reed hospital scandal in charge of the entire health care system?” My P is “Government incompetence leads to failure”, and my argument is that this statement is either true or not true. Either you accept the statement and are against nationalized health care, or you reject the statement and are completely naïve.

This is also how I argue against using the static keyword in Java. I recently told some people never to use the static keyword because “the static keyword destroys testability”. I believed this so much that I ended up creating instances of classes holding read-only variables that never change over the history of our business. Public constants anyone? No way, that would mean using static! In hindsight, my design was pretty silly.

Arguing against over-use of inner classes is another place I employ this logic. I encountered a few classes that were, in my opinion, entirely too long, and each had several inner classes inside of them. The rationale I was given was that classes should be inner if they are only ever used within that enclosing instance. My response was that the result of applying this rule would transform any Java application into a single .java source file with thousands of inner classes. "P ∨ ¬P". Either the rule is true or not true.

The truth about these three scenarios lays somewhere in the middle. The government is rife with incompetence, but that doesn't doom a national health plan (in and of itself, that is). The static keyword is a barrier to testability, but that doesn't mean it isn't without its uses. Inner classes too serve a purpose, but knowing when and where to use them is a bit of a fine art.

In general, arguments that rely on the law of the excluded middle are tenuous. The author may be making a true statement, but it's probably not true by virtue of the reasons given. You can't reject the author's thesis, but you probably can reject the reasons given. You can be on the lookout for this line of reasoning in your readings, but for me the real insight comes when you're looking at your own thoughts. What are the things you hold to be true that come from reason like this?