It's been a while since I wrote parts 1 & 2 of my promised three part analysis:
1) How hard can one push prisoners who are probably associated with terrorism or terrorist groups? Where is the boundary of unacceptable treatment? Is this boundary dependant on the circumstances? 2) How does one handle the status of prisoners taken in ongoing hostilities if they are POWs? if they are "unlawful combatants", but there is not enough evidence to convict them of a specific war crime? Even the most casual observer might have noticed that I have yet to address #3: 3) How does one determine the most likely possibility and the range of possibilities from conflicting reports from conflicting sources?) Listening to a number of different people from a number of different places in the political spectrum argue for radically different sets of facts from the same observation I've noticed that people often have a cut criterion that appears to be based on their beliefs. For example, conservatives talk about the liberal bias. In the '60s and '70s, Marxists I knew talked about the inherent pro-capitalistic bias of the US and European papers. Conservatives I know use to tell me that Rush is more accurate than the mainstream media. Many were convinced that the news media was covering up the strong evidence that Bill Clinton murdered both Vince Carter and Ron Brown. When, at the request of friends, I went to talk with Dennis Kopinski (sp) supporters at their house, I was amazed that many of them laid most of the worlds ills, including the Balkans, on people the US put in power. For example, at that meeting,I was told that Milosovitch was really a CIA tool that we decided was bad only after he stopped obeying orders. One consistent pattern I've seen was a data cut that was consistent with pre-set beliefs. Information that confirms those beliefs is considered reliable, while information that contradicts those beliefs are suspect. It's a natural tendency of humans to do this, and one could go into a long analysis of why. But, this post will probably be L3 without this analysis, so we'll postpone that discussion to another time. I hope we can take this human tendency as a given, and then look at techniques that might help us overcome it. I will start the analysis by using a very old technique: looking at how this question has been solved in an easier context and then seeing if the lessons learned there can be applied to this problem. The context that I will consider is one that has strongly influenced my thinking, both professional and personal, over the last 15-20 years. It is the solving of reported field problems at my first job, with Dresser Atlas. When I joined Dresser Atlas, I noticed a vicious circle between operations and engineering. To give a bit of background, our group was responsible for the design and support of nuclear tools that were run by operations in customers' oil wells. Operations were directly responsible for the accuracy and reliability of the tools. Since the tools were designed and characterized by engineering, fundamental problems were referred to engineering. This usually happened in the "fire drill" mode. A customer would express significant dissatisfaction with our service, indicating a possible cut off of Atlas from working for them. The field would report the problem that they saw as responsible for the problem and make an urgent request to engineering to solve the problem. Engineering would stop it's long term work for anywhere from a day to two weeks, investigate the reported problem, and respond. Most of the time, it was an exercise in futility and frustration. Engineering could not find the reported problem. Indeed, many times, the work gave strong indications that the reported problem was very unlikely to exist. Engineering would report this back to the field, frustrated at losing time in the development of new tools, which were also demanded by the field. The field became frustrated and angry at what they considered the culture of denial in engineering. At first, I simply fell in with the engineering party line. I saw how we wasted time on fire drills chasing close to impossible claims from the field. But, after a while, I talked with enough people in technical services (a field interface group), and talked with enough customers to determine that the field problems were not just a fantasy, or the result of bad operations practice. Something was going on, and the reports were good faith efforts to describe what that something was. One particular instance stands out for me. A district engineer reported a problem. I looked at the reported problem, and saw that it's existence was inconsistent with a wealth of data that I had analyzed. Since these data were carefully taken, and were taken with a number of different tools of the exact same design, I was pretty sure that the reported problem did not exist. I called the engineer back to report my findings. He responded, in a resigned voice, well I'll just have to try to solve the problem myself then....feeling that, once again, engineering let him down. I worked hard to keep him on the phone. I told him that I believed that he had a tool problem, and that I didn't think that I had established that it was an operations problem. All I did was eliminate his guess as to the cause of the problem. I then proposed that he duplicate a test that engineering had run. If he got the same results we did, then we would look at one set of possible problems. If he got different results, then we would look at another set. Either way, we would (roughly) cut the problem in half. I convinced him to do it, and within a few hours, I got a somewhat embarrassed call from him. When he ran the test, and got the same answer that I did, he started to think about the problem he had. He found an operations issue that he fixed, and the problem went away. I told him not to be embarrassed, because engineering has made mistakes too. I said the next time the problem might be mine and proposed the deal that we both would refrain from finger pointing when we solved problems together. This suggestion was quickly accepted, and we went on to work very well together after that. Obviously, this tale of a success of mine has put me in a good light, but that's not the point, honest. The point is that this technique found success in problem solving that had eluded both engineering and operations before this time. I thought a great deal about this success and have made a few generalized rules from that. 1) Even reports which, as given, could not be true can be mined for critical information: What was reported in my example was not factual. But, there was an important fact associated with it: the engineer observed something that made him reach the conclusion that he did. Using those facts for what they were was instrumental in making a breakthrough out of a vicious circle. 2) Having a teammate with a significantly different perspective look at the problem is usually very helpful: The engineering perspective, while perfectly valid, was still limited. Engineers are regularly bitten by their hidden assumptions, no matter how much they work at objectively trying to solve a problem. Field people's intuitions were formed in a different environment than engineers and scientists. When I was open to the reality of their problems, even when their diagnosis was impossible, I found that I could solve problems that I wasn't able to address without their help. 3) It is impossible to be totally open to every possibility; while getting locked in a particular mindset will blind you to obvious solutions. This seems like a contradiction, but it really isn't. It is a balance point. One cannot be totally open minded to every possibility, because the possibilities are virtually endless. One joke I use to make about this when we were stumped concerning the source of a problem was "Well, I don't think we need to look at the effect of the barometric pressure in Cleveland on our data." In other words, we needed to be open minded, but not too open minded. What I have found successful is establishing a hierarchy of likely causes. One investigates what one thinks as the most likely cause first. If that's it; great. If not, then one uses the information obtained in that investigation to rerank the causes and then go on to the next one on the list. Let me give an example of how this works. One favorite debugging technique for both hardware and software is "divide and conquer. Often times, when there is a problem, there is a whole string of possible causes. This string can often be organized in such a faction that one can make a test that usually eliminates half of the potential candidates, one way or another. If the test shows the problem, then it's "before" the test; if not, it's after. This is an extremely useful technique. Team members who keep on insisting that the error is in the "cleared" part of the tool/software, are usually rightfully considered a bit pigheaded about their opinions. But, after going over the remaining possibilities carefully for an extended period; it is most reasonable for a team member to suggest one revisit the original test. Possibly it didn't test exactly what the team thought it did. Possibly there is a subtle error in the first part of the process that only manifests itself later in the process. Anyone who has done engineering or software has probably had experience with this. Realistically, we know that the divide and conquer technique isn't perfect; it gives false indications once in a while. But, we also know it is extremely useful. So what does one do? One gives a significantly lower weight to the possibility of the "cleared" area containing the problem and thinks of another "divide and conquer" that can be used to narrow the problem down even further. But, one doesn't eliminate the possibilities, but keeps them low on the scale until the time that the weights for the other possibilities start to approach those weights. This is not an exact science, to be sure, but a balance point, which optimizes effort, is obtainable. 4) Calibrating against past observations is very helpful. This is clearly true for equipment, but I also use this with people. I kept a list of field people I could count on for good observations, as well as those who refused to see anything outside of their blinders. I listened much more carefully to the observations of the former than the latter. In addition, I kept track of who has proven me wrong in the past. Not, of course, to get even, but to pay special attention to their statements in the future. Like step 4, this is a matter of weights, not binary functions. Even folks who were generally unreliable in defining what was wrong can see something that's useful and communicate it in a somewhat garbled fashion. But, if reliable field people don't see a problem, and less reliable ones do, then the problem is less likely to be an engineering problem. I will stop here, having given 4 rules of thumb, but not yet applying them to politics. I'll add a couple more that relative to politics when I do that. But, I wanted to see if there was any reaction to these rules before I applied them....and, of course, this post is long already. Dan M. _______________________________________________ http://www.mccmedia.com/mailman/listinfo/brin-l