January 02, 2007: Augustine on (in?) the Brain

For me the most fascinating part of Augustine's Confessions is his attempt to come to terms with the concept of time. From the very beginning he makes it clear that he is up against a serious challenge:

What then is time? Provided that no one asks me, I know. If I want to explain it to an inquirer, I do not know. But I confidently affirm myself to know that if nothing passes away, there is no past time, and if nothing arrives, there is no future time, and if nothing existed there would be no present time. Take the two tenses, past and future. How can they ‘be’ when the past is not now present and the future is not yet present? Yet if the present were always present, it would not pass into the past: it would not be time but eternity. If then, in order to be time at all, the present is so made that it passes into the past, how can we say that this present also ‘is’? The cause of its being is that it will cease to be. So indeed we cannot truly say that time exists except in the sense that it tends towards non-existence.

Ultimately, he can do little more than clarify his terminology, anticipating Wittgenstein by concentrating more on how the terms are used than on what they mean or are:

What is by now evident and clear is that neither future nor past exists, and it is inexact language to speak of three times—past, present, and future. Perhaps it would be exact to say: there are three times, a present of things past, a present of things present, a present of things to come. In the soul there are these three aspects of time, and I do not see them anywhere else. The present considering the past is the memory, the present considering the present is immediate awareness, the present considering the future is expectation.

What has interested me the most is the extent to which our increasing knowledge of the physical brain has turned out to align nicely with Augustine's metaphysical soul-concept. The "present of things past" anticipated that engram that Lashley invested so much of his life in trying to find without success, although within the last ten years in appears that Richard Thompson and his colleagues at USC have managed to associate it with a localized region in the cerebellum. Meanwhile, we have Gerald Edelman to thank for demonstrating that the "present of things present" is actually a "remembered" present. New BBC NEWS has reported results from Washington University concerning the "present of things to come," presenting evidence that this, too, is localized, in this case in the left lateral premotor cortex, the left precuneus and the right posterior cerebellum. It is nice finally to home in on some good news at the start of a year that began with so many ill omens!

December 26, 2006: "Clinical" IT

I would like to continue my thoughts on the question of whether or not there is a suitable academic foundation for "service science" as inspired by my reading of Decision Support Systems: An Organizational Perspective, by Peter G. W. Keen and Michael S. Scott Morton. This time I would like to begin with a question posed to me last October by a friend working at Accenture: He wanted to know what Accenture could do to make IT organizations better at what they do. My point of departure for answering this question involved an analogy from medical practice, viewing the IT organization as responsible for the "health" of the organization. I argued that IT developers needed to take a clinical approach to "taking the history of the patient," who comes in with some set of possibly pathological symptoms. I then extended the analogy by arguing that enterprises need "health maintenance," rather than "illness treatment." Ultimately, this conversation did not progress, possibly because the analogy was too much of a departure from the "normal practices" (as in "normal science") of both Accenture and its customers.

Imagine my surprise then in discovering that Keen and Scott Morton proposed a "clinical" approach to the development of decision support systems! What was particularly interesting was that they recognized two different levels of diagnosis that need to be performed by IT developers. The primary level of diagnosis relates to what I called "taking the history," identifying what needs to be changed and how IT can facilitate that change. However, they insisted that it is also important to diagnose symptoms of resistance to change, because, if the resistance is not "treated," it is not going to matter very much how effective the proposed solution is. The forces of resistance can undermine even the best of ideas, no matter how well they are implemented!

I then noticed in the Bibliography that Keen had been advocating this clinical stance since 1975, when he wrote a Sloan School Working Paper on the subject. That means that the idea has been around for over 30 years but has never really "taken" in the world of enterprise software. I suspect one reason for this is that this kind of thinking does not fit into the specializations found in most academic curricula. One does not go to business school (or, for that matter, computer science departments) to learn about "the socio-technology of diagnosis," let alone the intellectual skills required for such diagnosis, such as an understanding of the subjective (as well as objective) motives behind speech acts or the use of narrative as a tool for "thinking in time." As a result, Keen's insights seem to have faded into obscurity.

Meanwhile, the history of attempts to make IT useful to the enterprise continues to repeat itself. As Marx said, what is tragedy the first time around becomes farce with the next iteration. However, he did not say anything about any subsequent repetitions!

October 04, 2006: The Dangerous Concept of "Pattern"

It may be the many of the exaggerated claims recently being promoted, whether about digital libraries or sharing poetry, all fall back on the assumption that "pattern" is a mathematical concept that can be readily manipulated by powerful software. The fact is that this is a dangerous misconstrual of the concept of "pattern," which can only impede efforts to engage software to facilitate the management of documents, whether those documents are the contents of a digital library or someone's favorite collection of poems. When a word is capable of causing that much trouble, my general inclination to be rid of it, and that is what I propose to do.

Rather than simply expunge the use of the word "pattern" from our current discourse, I would like to modestly propose that we consider, as an alternative, Gerald Edelman's concept of "perceptual categorization." This concept was first discussed at length in Edelman's Neural Darwinism and progressed to the primary leitmoitv in his study of consciousness, The Remembered Present. While this may strike some as little more than a word-game move, I believe there are significant ways in which Edelman's model of how the brain forms perceptual categories constitutes a departure from mathematical models of patterns.

Most important is that, while there are a variety of objective criteria that can be used to identify and define patterns, perceptual categorization puts the human subject (the perceiver) squarely in the middle of the loop. If document management is ultimately about supporting sharing and if sharing is to be an intersubjective activity (and what else could it be in any practical setting?), then we cannot abstract the subject out of the picture (at least, with my own personal convictions, I cannot). If we further follow Edelman’s lead, we also encounter some interesting properties of perceptual categories and how “wet brains” deal with them.

First of all, perceptual categories are fluid. Edelman firmly rejects the idea that any part of the brain is implementing anything like a store-and-retrieve memory system. Rather, categorizing is something the brain is always doing (probably even when we are dreaming); and a lot of that categorizing is recategorizing.

Equally important is the brain evidence Edelman has mustered that demonstrates that different parts of the brain deal with categories in space and time, respectively. Most pattern theories tend to assume that patterns in time are the same as patterns in space, because you can just include a time dimension as one of your “spatial” axes. However, when you bring human subjects into the picture, time is not just “another dimension.” We have known this since Aristotle (read his separate treatises on physics and memory to give your own gray cells a real jolt); and we are just beginning to discover how this plays out in our brains.

This then takes me to my third point: As I previously asserted, the discursive dimension is a dimension of performance. Because it is a dimension of performance, it is a temporal dimension and therefore firmly requires temporal perceptual categorization. (At this point you need to shift from Aristotle on physics and memory over to his “Poetics!”)

September 05, 2006 (2): My Life and Hard Times in Requirements Analysis

From 1978 to 1981 I worked at General Research Corporation on problems of requirements analysis for the Army. I had taught programming methodology at the University of Pennsylvania at a time when people were beginning to use the term “software engineering” instead of “programming.” The focus on methodology grew out of the recognition that the design and construction of computer programs should be as much an engineering discipline as the design and construction of bridges or electronic devices. Engineering was about building something for someone else’s benefit; and that third party needed some confidence that the resulting artifact would do what it was supposed to do, reliably and safely. How would a software engineer determine what that artifact was supposed to do? It was assumed that the party for whom the program was being written would initiate the engineering process with some set of requirements, and software engineering methodologies were concerned with how one could effectively and productively proceed from those requirements to a reliable program that would satisfy the beneficiary.

Unfortunately, the real world has never been particularly sympathetic to abstract engineering methodologies; and, where software is concerned, the problem tends to start right with that beneficiary. How does anyone, the beneficiary or any programmer, know whether or not the requirements provided by the beneficiary are an accurate representation of what that beneficiary really wants? The history of software engineering has been plagued with case studies that begin with the sad truth that requirements are actually a very poor representation, particularly if the beneficiary does not have a clear idea of what the program is supposed to do; and the lack of a clear idea is often a product of the unholy alliance of a beneficiary who does not appreciate what it is reasonable to expect and a software engineer eager to promise the world.

Thus, it is not enough for the Department of Defense to want to protect the United States from missiles with nuclear weapons on their warheads. While that is an understandable request, it is not a requirement that can be translated into the design of a computer program. Knowledge engineering operated under a similar illusion: One cannot simply identify an expert, say in the area of medical diagnosis, and “engineer” a “representation” of the “knowledge” behind that expertise. When I worked at Schlumberger, I had the good fortune to work alongside some of the best minds who knew how to interpret the complex and obscure measurements taken in the boreholes of potential oil wells; but I quickly learned that they did not live in a world of requirements and specifications, which could then be converted into computer software.

Fortunately, I discovered, essentially by accident, an alternative approach. Rather than working among my colleagues in the software systems group, I asked to have an office in the wing in which all these experts worked. Using a Xerox Lisp Machine, I would prototype programs to interpret test cases of these measurements, yielding displays of both the measurements and the interpretations. This became an excellent conversation-starter. An expert would wander past my office, see the display and come in for a closer look. Examining both the data and the results, the reaction would almost always be the same: “Why did your computer do a damn fool thing like that?” My reply was also almost always the same: “Why is that a damn fool thing? I just did what the training manuals said!” This would start an extended lecture on why what you did in the real world had nothing to do with what the training manuals taught you; and, enlightened by that lecture, I could go back to work on the program. Essentially, I had discovered a user-centered, evolutionary approach to identifying and satisfying requirements that reflected what the beneficiary really wanted. Since those days I have discovered that I am far from alone in appreciating this methodology, but my opinions are still very much in the minority.

In retrospect, however, I can appreciate why this methodology has not caught on in the software engineering community; and the reason can be traced back to that distinction, first raised in Plato’s “Republic,” between lexis (word) and praxis (act), which has become one of my favorite topics. The idea that requirements can be “represented” at all presumes the construction of an artifact that is basically a lexis structure, even if the “words” are elements of a formal language, rather than a natural one. At Schlumberger, however, I came to understand the nature of requirements by becoming familiar with the praxis of the experts who could come into my office and make fun of what my prototype programs were doing. Unfortunately, documentation is the bread and butter of engineering methods, whether they are based on natural language or some combination of formal representational systems (blueprints, flow charts, algebraic specifications, etc.). There is no place for praxis in such documentation. Indeed, as I have already observed, John Seely Brown and Paul Duguid have gone so far as to call those documents “Abstractions detached from practice [that] distort or obscure intricacies of that practice.”

The problem, which has been a recurring theme in this blog, is that lexis structures are static, which makes them conducive to representations, which, in turn, are conducive to analysis. Praxis, on the other hand, is, by its very nature, dynamic, making it particularly elusive to most methods of analysis. However, rather than ignoring praxis because it eludes our methods, we should be seeking out alternative methods that, to invoke the language of Richard Neustadt and Ernest May, facilitate our ability to “think in time.” This is a lesson that still continue to grow on me.

July 04, 2006: Does the Brain have State?

One consequence of trying to draw upon our understanding of digital computers to enlighten our understanding of the brain is that the former is grounded in the concept of state. The consequence is that we assume that we can apply this concept to the brain, but is this a valid or even desirable assumption? The usual argument is that, however, large the number of neurons involved may be, the concept of state, itself, can scale to any magnitude. So, while an accurate state description may be unwieldy, it is still (at least in theory) possible.

However, the real question we should be asking is whether or not it make sense to describe the brain in terms of a static object. Where many processes are involved, we can still make analytic progress by "freezing time" and examining the "state" of those processes at such a "frozen instant." However, that abstraction is only useful if we can think in terms of how the state we are examining is the result of a transition and what similar transitions are possible to proceed from that state. This is where we may run into trouble by applying such thoughts to the brain. The intimidating truth is that every single neuron is a dynamic processes whose nature we are still trying to understand. We talk about these cells firing as if that activity can be abstracted into a binary state, but that abstraction may be too coarse to explain brain behavior when matters such a memory are involved.

I have invested a fair amount of my own mental effort in trying to make sense out of a hypothesis that Gerald Edelman made about memory. His hypothesis rejects the idea that biological memory is based on a store-and-retrieve model. Instead, he argues that what we remember arises from ongoing processes of refreshment that take place in the brain. Edelman is thus talking about a dynamic process that, by virtue of its complexity, cannot be readily abstracted down to transitions across static states. I have no idea with Edelman's hypothesis will ever be settled in my lifetime; but I do know that, however we may choose to think about the brain using the digital computer as a model, in just about any practical setting we have not done very well by thinking about human memory in terms of a database! This is likely to be yet another situation in which it is more important for us to develop better skills for "thinking in time."

June 13, 2006: Control and Consequences

I want to get back on the theme of the "half life of technical education" and why I am concerned about it. I suppose it all has to do with why I am trying to tilt at the windmills of technical education (and probably just about any other form of specialized education) in the first place. My concern is basically one of objectives, because it seems to me that the focus of such educational programs always comes down to some approach to controlling the world. Now that seems like a perfectly reasonable way to go, particularly in the mind-set of post-Enlightenment Western civilization; but, as we need to become more aware of our role in the world at large, we must not fool ourselves into believing that it is the only way to go or that "control solves everything." What is often overlooked when we focus to intently on control is that the world is a complex case; and, whatever control we may have, it will never be a handle on all that complexity. Thus, at the very least, we need to live by the motto that control has consequences.

This is particularly important when we try to reduce everything we do to making decisions and acting on the results of those decisions. In this regard I need to draw attention to (and recommend) the book Thinking in Time: The Uses of History for Decision Makers, by Richard Neustadt and Ernest May. This book is basically a series of case studies, each of which involves an act of presidential decision making in a time of crisis. The theme behind the entire book involves the way in which Neustadt and May characterize what they mean by "thinking in time." Basically, it involves asking two fundamental questions:

1. How did we get into this situation?
2. Given a course of action to consider, what will be the consequences of following that course?

In other words "thinking in time" involves more than analyzing a "state" in isolation: You have to understand that path through past states that led up to the present state; and, on the basis of your understanding that (and other) paths, you need to make a well-informed guess as to where the path out of that state (determined by the course of action) will lead (and, to invoke chess language, you have to look ahead more than a single move).

This also brings in an important reflection of decision support technology that goes all the way back to the pioneers of that technology: Peter Keen and Michael Scott Morton. Their first book on the subject, Decision Support Systems, begins by drawing the distinction between efficient and effective decision making. The punch line, of course, is that it is always necessary to strive for the latter, rather than the former. I believe that one of the hazards of the way in which specialized education is taught (if not of the subject-matter itself) is that efficiency tends to get the upper hand over effectiveness, simply because it is easier to evaluate efficiency, while evaluating effectiveness demands all the subtleties of "thinking in time." (We are back in the world of looking for your keys where the light is better, even if you know you did not lose them there.)

So perhaps there should be some corner of our educational process that makes sure we do not forget that it can be all right to just live in the world, without necessarily controlling (or feeling you can control) it. I do not mean this as a granola-based go-with-the-flow philosophy. Rather, to reflect on the quote in my Blast, you should be able to live in the world without "fear, superstition and pettiness," because the world throws so much at that stuff in our path that we should delude ourselves into believing the the only way to deal with it is to control it!