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 22, 2006: The Classroom of the Future

Things have been quiet here because this past week I had the opportunity to sit in on a workshop being conducted for the benefit of about half a dozen principals from the California public education system. The purpose of the workshop was basically to let them know what was out there on the "bleeding edge" of new technologies, particularly information technologies, as a way of getting them to offer their own visions of the classroom of the future. Listening to their presentations on the final day, I was struck by a distinction that I first raised in discussing the opposition of lexis and praxis: While most technical presentations I attend are heavily noun-based (usually concentrating on features and their attributes), the grammatical foundations of all the presentations the principals gave were heavily (and refreshingly) rooted in verbs. Given my preoccupation with this need to give "equal time" to both nouns and verbs, I was very glad to see that attention reflected in the way in which these representatives of the educational community expressed themselves.

However, following the presentations, the discussion took a twist that was also very interesting. Whenever the conversation turns to any form of change management in an educational system, whether or not it involves new technology, the question that always arises involves what it will take to make the change happen in a setting that is painfully strapped for resources and always seems to be the victim of prevailing political trends. One suggestion that was raised was that we could not count on change management coming from the government; so it would have to come from the commercial sector, which, after all had the most to gain (or lose) from the quality (or lack thereof) of public education. At this point I realized that one of the principals had invoked the language of scientific management on one of his slides, although, to his benefit, he realized that one had to think beyond questions of "productivity" to questions of "customer satisfaction." Nevertheless, it made me think about the cultural context in which we think of the stakeholders in our educational system as "customers."

This then reminded me of a book that I read with great relish at the beginning of this year: Education and the Cult of Efficiency: A Study of the Social Forces that have Shaped the Administration of Public Schools, by Raymond E. Callahan. Never mind that this book was published in 1962; the extent that it was still relevant today was, to say the least, chilling. In a nutshell this book provided an excellent review of the principles of "scientific management," which basically originated from the work of Charles Taylor, and then discussed the ways in which public school systems tried to embrace those principles to the general detriment of the quality of education. Callahan recognized that the overall goal of scientific management is efficiency of production and that this goal is, at the very least, at cross-purposes (if not fundamentally opposed) to goals of education, which, to invoke terminology I raised on June 13, have more to do with effectiveness than efficiency. Then I realized that, for all the lip service that has been paid to getting beyond the narrow view of scientific management in the enterprise, whether it involves "total quality," "knowledge management," or rhetoric about "customer relationships," most enterprises are still locked into that goal of efficiency of production, even if, in the Brave New World of services and globalization, they do not always have a clear idea of what it is they actually produce! Consequently, it may be a vain hope to expect that change in the educational establishment will come from a private sector that may be willing to talk about the value of effectiveness "in theory" but, when it comes to practice, it still locked into thinking about efficiency of production.

June 07, 2006: The Road to Lexis and Praxis

I figure I probably ought to offer some justification as to why I invoked Greek terminology from Plato and the general plan of Kant's Critique of Pure Reason in yesterday's entry. Accounting for Kant is definitely the taller order, particularly since I feel I am just getting beyond the Cliff Notes stage in my ability to read him. So I may end up postponing that question until I have given the Critique a second reading (which will definitely be more thorough than my first reading, meaning that this postponement is likely to take some time). On the other hand I feel I can address the justification of my invoking the lexis-praxis terminology at the present.

I suppose I can begin that justification by repeating yesterday's citation to the paper by John Seely Brown and Paul Duguid ("Organizational learning and communities-of-practice"). I first read this paper when John was running Xerox PARC and I was involved with knowledge research at the Palo Alto laboratory that Fuji Xerox had established (which was on the same campus as PARC). The most influential passage in this paper for me was in its second paragraph:

Formal descriptions of work (e.g., "office procedures") and of learning (e.g., "subject matter") are abstracted from actual practice. They inevitably and intentionally omit the details. In a society that attaches particular value to "abstract knowledge," the details of practice have come to be seen as nonessential, unimportant, and easily developed once the relevant abstractions have been grasped. Thus education, training, and technology design generally focus on abstract representations to the detriment, if not exclusion of actual practice. We, by contrast, suggest that practice is central to understanding work. Abstractions detached from practice distort or obscure intricacies of that practice. Without a clear understanding of those intricacies and the role they play, the practice itself cannot be well understood, engendered (through training), or enhanced (through innovation).

This was a pretty radical position for a representative of "The Document Company," since the primary medium for those formal descriptions was the document! So I saw in this paper the invocation of a fundamental opposition between the document-based and the practice-based. In my own research (which, at that time, was focused primarily on the frustrating problem of organizational memory) I tried to generalize this to an opposition between the noun-based and the verb-based, because, while documents certainly used verbs, the document itself was an artifact; so both the documents themselves and the formal descriptions that were often the content of documents resided firmly in the world of nouns. They were, indeed, "abstractions detached from practice." (For a while I was even using the phrase "communication artifact" instead of "document.")

I was quite happy with pursuing the opposition between nouns and verbs until I got involved with reading Kenneth Burke's Grammar of Motives. There I discovered that Spinoza had also been interested in such oppositions. Burke cited three variations, all of which I felt could be relevant: passive-active, object-subject, and product-producing (which resonated nicely with my interest in the term "communication artifact"). With this as background, along with a natural desire to seek out generalizing categories, I was primed for the opposition of lexis and praxis that Jurgen Habermas invoked in the first chapter of his Theory and Practice. This led me to explore the specific definitions of both of these words in the Perseus online dictionary of classic Greek. The nice thing about the entries is that they invoke citations from classical sources; and that is how I discovered the citation of lexis and practice in Plato's "Republic" (along with a context-based translation of those words)!

Now Plato's context is concerned with giving faithful accounts. More specifically, he is addressing relating "some word or act of a good man" to others; and this is where the words lexis and praxis appear in the original Greek. However, this takes us back to the original theme of the Brown-Duguid paper. At the end of the day, work is all about both words and acts. Our training in information technology has served us well with formal descriptions in the domain of words; so, like the drunk under the lamp-post who looks for his keys because the light is better there, we try to assume that only the words that matter, because they are what we know how to describe. In so doing we invoke abstractions that distort our understanding of acts.

What is to be done? Clearly, we need a better handle for describing and talking about acts that can stand up to the formal descriptions we invoke for words. The first volume of Habermas' Theory of Communicative Action proposes such a framework for talking about acts. However, an account of this framework is very much another story; and I shall postpone it to another entry (which I can probably write before I get around to Kant)!