- Success and Failure of Projects and Strategies
- Core Competencies
- Education
- The Need for Understanding: Abstraction, Precision, Explicitness
- Abstraction: The Way to Put Management in Control
- Basic Structuring Constructs
- Business Rules: Precision vs. Handwaving
- Tacit Assumptions and "Evident Truths"
- Specifying Problems and Solutions
- Where to Start and Why: Business Domains
This chapter is from the book
This chapter is from the book
This chapter is from the book
Tacit Assumptions and "Evident Truths"
"I mean, what is an un-birthday present?"
"A present given when it isn't your birthday, of course."
Alice considered a little. "I like birthday presents best," she said at last.
"You don't know what youre talking about!" cried Humpty Dumpty. "How many days are there in a year?"
"Three hundred and sixty-five," said Alice.
"And how many birthdays have you?"
"One."
"And if you take one from three hundred and sixty-five, what remains?"
[...]
"[A]nd that shows that there are three hundred and sixty-four days when you might get un-birthday presents—"
"Certainly," said Alice.
"And only one for birthday presents, you know. There's glory for you!"
Lewis Carroll, Through the Looking Glass [C1872]
Having a well-structured, explicitly available system of concepts and constructs is not sufficient for writing good specifications. We also need to articulate the tacit assumptions, i.e., make explicit the facts that "everyone knows." Different people may know and articulate different data about facts,39 i.e., they may have different and mutually inconsistent viewpoints about the facts, and unless the contents of their viewpoints are made explicit, this will not be determined or discussed. To make the contents explicit, we ask questions in terms of the system of concepts and constructs that we introduce and use. For example, when we discover business rules, we may determine that some of them are written and some are unwritten; and also that some of them are due to legal obligations while some are due to customary behavior within a specific business context [KS1997]. Some of these rules may be missed because they are considered "obvious," "assumptions that everyone knows," "never explicitly mentioned," and so on. At the same time, these rules are often of essence, for example, in contract negotiation, especially in establishment and persistence of long-term business agreements. Unfortunately, "in what passes for high-level discourse, insistence on the obvious can be made to sound trivial and therefore not worth saying" [B2000]. We should avoid this expensive fallacy in our modeling work (and elsewhere).
Tacit assumptions are worse than unformulated hypotheses: in most cases, there is only one such hypothesis (and it is either correct or not), while inconsistent tacit assumptions about the same fact used by different people cannot be correct at the same time. In addition, the tacit assumptions left out of a specification must be figured out—i.e., made explicit—by those who will realize the relevant fragments of the specification, often IT developers who are not (and should not be) subject matter experts. This is a recipe for failure also known as "business rules defined by developers." More generally, the meaning to the person who realizes the specification is often not the same as the meaning to the person who wrote that specification [S2001].
Ignorance—real or perceived—of the subject matter helps in making the tacit assumptions explicit. As early as 1969, P. Burkinshaw urged this: "Get some intelligent ignoramus to read through your documentation; [...] he will find many 'holes' where essential information has been omitted. Unfortunately intelligent people don't stay ignorant too long, so ignorance becomes a rather precious resource. [SE1970].40 This essential information often is about the basics of the business domain; and when the information is omitted—often because it is perceived to be clear to everyone—disasters may happen. Therefore, the "intelligent ignoramus" ought to be the most active participant in the specification process from the beginning rather than act just as a(n afterthought) validator or tester of existing specifications.41 Good business analysts fulfill this role from day one (or zero) of a project.
Tacit assumptions may be hidden in a huge amount of information that is supposed to be deep and therefore important. To quote George Orwell, "[w]e have sunk to such a depth that the restatement of the obvious has become the first duty of intelligent men." Discovering and elucidating such obvious assumptions—the background knowledge that is supposed to be shared among the stakeholders—usually leads to better understanding and modeling of the structure underlying the huge amount of detail and is of extreme importance. Different viewpoints of different stakeholders determine their tacit assumptions and the perceived need to elucidate these assumptions. The modeler, together with the stakeholders, discovers, articulates and composes the (possibly inconsistent) tacit assumptions into an explicit model appropriate for the context(s). Various viewpoint specifics are then formulated in terms of this explicit model. More details about composition are provided below, in Chapter 2.
Some "evident truths" are not beneficial. We can follow the lead of mathematics where the abandonment of the concept of "evident truths" sometimes led to very important and far-reaching results. However, before a decision whether to abandon an "evident truth" can be made, that truth must be explicitly formulated, i.e., the tacit assumptions about it must be made explicit. This should happen not only in mathematics but also in science, engineering, business, and information management.
When we evaluate and sometimes abandon "evident truths" in information management, we often return to basics. In other words, we reuse excellent existing ideas that have been around for a long time, but either have been forgotten (and perhaps reinvented under different names) or have been considered too obvious to be mentioned or too abstract (as the map of the London Underground). These "too abstract" ideas have been successfully presented to and used by business SMEs and decision makers (for examples referring to the experience in large financial firms, see [KA1999, BK1999, G2001]) on the one hand, and by high school students [LS1997] on the other hand.
Rejecting an approach, or an idea, just for the reason that "nobody does it that way" is extremely counterproductive. Certainly, some new approaches do not lead to success, but the reasons for rejection ought to be more specific. In software engineering, as noted by David Parnas in his talk at ICSE 2001, relying on currently fashionable software engineering ideas and advanced technology often implies looking for magic tools that will (supposedly) help to deal with the horrible legacy that they keep creating. We need to do much better than that.