Binary Thinking in an Analog World

I'm often exasperated at my inability to clearly distill a concept to it's essentials. I've been chastised for repeating myself, and it's a fair criticism. But then, I'm a trained professional engineer and not a professional communicator. Glenn Greenwald, who is a professional communicator, expresses a point I've struggled with, but which is one of those things I've tried to articulate many times.

At the heart of this process lies a binary moralistic view of the world, one which seeks to define every conflict and political challenge, both foreign and domestic, as a battle of Good versus Evil. The crux of this mindset is the continuous identification of an Enemy, one which embodies Evil and which must be stopped, typically destroyed, at all costs. No competing considerations, no rational arguments, no counter-balancing objectives, not even constraints of reality or resources, can compete with the moral imperative of this mission. The mission of destroying Evil trumps all.

And the converse then also falls comfortably into place: those who seek to destroy Evil -- whether it be America, or President Bush, or the right-wing political faction that has supported the Bush presidency -- are, by definition, the embodiment of Good. Thus, whatever steps they take, whatever instruments they employ in service of their mission, are intrinsically justifiable because, by definition, they are employed in service of the Good.

The binary thinking is the standard operating procedure of the right wing. Doug's screeds are the embodiment of that type of simplistic thought. The problem really isn't in thinking in binary, but doing it in a macro sense. It's too difficult for them to examin the details.

I often think about real-world problems in binary terms, because unlike communicating it's something I'm actually good at, and I use the same sort of process I use in debugging programs to try and find rational ways to debug political or cultural problems. Indulge me a moment while I get a bit geeky.

A computer program, no matter how complex the code, or how complex the processing, is linear. Even "multi-threaded" programs are done one command at a time. They just happen in parallel but the convergence points force linearity.

For example... suppose you have measurable points in a program where, after various conditions are evaluated, you have observable conditions. You can effectively freeze a program at any point and examin all the conditions in the environment at that point, but usually debugging is done at points that are the most easily observable. Label those observable points with a letter and program code in between with dashes.

So say you have this;

A -- B -- C -- D -- E

The letters are observable states in a program. Lets say the expected state for "E" is 99, but when observed it is 5. That's a problem we need to solve. What makes the most sense to logically determine why E is in error? Do we go back to A and see what it's state is? Do we look at the "--" between B and C? No, we know what state D should be so we look at it. Is it correct? If it is, we know the error is in the code between D and E and have isolated the smallest amount of code necessary to figure out where the error is. After we fix it, we run the program again and expect to see E = 99. But suppose it's still not correct?

That's where debugging computer programs become exceptionally difficult. We have to go back to looking at the code between D and E, and we see that one of the binary decisions the code makes is dependant on the state of some condition between B and C. That creates a condition where D is always what we expect, but the condition between B and C has a bug that just coincidentally allows D to be correct, because D isn't dependant on it.

That type of problem solving technique can be applied to solving issues such as "terrorism" as well. Right wing thinking simply looks at E and says "E is wrong, we have to blow up the entire program".

Well, being good programmers, we know it's silly to just try and delete the entire program and re-write it because we'd likely end up with the same bug again. In the terrorism analogy, where is the bug?

As I described, the effect at a certain point (somebody strapping on a bomb belt) may be a result of an incredible number of conditions that lead up to that point. It could be their economic condition. It could be a local cultural problem (bat-shit crazy Imams). It could be emotional reactions to outside influences (foreign occupation). The list of conditions is vast.

Right wing thinking debugs the terrorism program thus; "The Quran demands Muslims convert or kill all infidels". They believe that bug can't be fixed, so you have to delete the whole program.

You can't fix the problem of terrorism without evaluating each condition and each piece of code fragment to find out where the error lays. You actually have to look at the code, and doing that in the real world means you have to interact. Asking them what the problem is might just be a good idea, then evaluate the way that seemingly unrelated conditions might actually influence each other. If a program is bug riddled, you have to fix each one, one at a time. Eventually you'll get the output you want.

It's really the only way, because the terrorism program is currently write protected and you can't delete it no matter how much you try. You can only debug it. And no.. nuclear weapons '= root.