Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Using Why Questions in Generative Analysis
Because Why questions are abstract, they often elicit answers in terms of high-level abstractions, such as moral frameworks, belief systems, group think, etc. that are generally not that useful for day-to-day software engineering, and that may even have little accordance with objective reality. It is common to ask Why aiming to get an explanation for something, but instead you get a justification based on high-level abstractions. The easiest way to deal with this is to switch to asking ConcreteQuestions that can be easily tracked back to objective reality.
In Generative Analysis we can use Why Questions in three distinct ways:
- To elucidate an existing map of reality.
- To extend an existing map of reality.
- To install a new map of reality.
All these uses depend on knowing, as we pointed out above, that Why can only be "answered" by an agreed map plus a cascade of Questions that are answerable by reference to that map. These may start out as more Why Questions, but they should rapidly reify into ConcreteQuestions.
In the next sections we will consider each of the three uses of Why Questions in turn.
Elucidating an existing map of reality
The Generative Analyst is most often concerned with elucidating an existing map of reality, because that is the activity of uncovering the ontology and metaphysics of an existing problem domain. The goal here is to get from abstract Why to concrete Who, What, How, Where, and When as quickly and efficiently as possible. Consider this example where A is a Generative Analyst, and S is a stakeholder. The system under investigation is OLAS (Orne Library Automated System), which is the library management system that we discuss in detail in Generative Analysis (see our book for complete details), and the stakeholder is a librarian:
A: Why does the Orne Library swap catalog information with Innsmouth Public Library?
S: Hah! The answer to that goes way, way back. You see, originally, Mr. Gilman who had a big shipping business back in Oh – 1930s – I don't know, anyway, away back – was going to leave a huge collection of books to Miskatonic. Anyway...we didn't get it and sometime in the 50's or so the town set up the Innsmouth Public Library to hold the collection. Not much public about it if you ask me – it's harder to get into than our Restricted Collection... We get to see their stuff, if they get to see ours, if you see what I mean, so we send catalog information back and forth.
A: Wow! That far back! I had no idea. About that... Can I ask what specific information you get from Innsmouth?
S: Sure – I'll give you a copy of the data we get from Innsmouth. It's updates to their Gilman collection.
A: Could we do that now?
If the above example, we have gone from a high-level "answer", that talks about history, motivations etc. to a very concrete request for specific information. It's fine to explore the more abstract issues with a stakeholder, but you must always maintain sufficient control to get to the level of abstraction you need to move the analysis forward.
Extending an existing map of reality
Depending on the stakeholder, Why questions can sometimes take someone right to the edge of their map of reality and this often triggers a strong emotional response as the person is invited into terra incognita (unknown lands). It is interesting that some of the old map makers labelled terra incognita with hic sunt dracones (here be dragons). Few people like going into the unknown because who knows what lurks there.
Consider the following example where A is the Generative Analyst and S is a librarian. The system under investigation is OLAS:
A: Why does Orne Library charge fines for overdue books?
S: We have to charge fines! We'd have no books left if we didn't.
A: I'm not suggesting that you don't – please let me rephrase that. What is the benefit of charging fines?
S: Well – it helps ensure that students return books when they should. It's unfair if a student can hold a book for too long – there is a lot of demand for some books, and we get complaints if they are not available.
A: Are there any other benefits of charging fines?
S: Not really – the whole process is a lot of work. If everyone behaved sensibly, we wouldn't have to do it at all.
The first stakeholder response is telling. In terms of Generative Analysis, "We have to charge fines!" contains the modal operator of necessity, have to, followed by a justification We'd have no books left if we didn't that contains a universal quantifier (no books left), so we have taken this stakeholder right to the edge of their map of reality beyond which there are no other known possibilities. Hence the emotional response. The analyst replaces the Why Question with a concrete What Question about benefits, and we get a useful answer. At this point we could drill down into the process for dealing with fines (we would have to do that at some point anyway) or we could try to extend the stakeholder's map. We do this by framing a Question that takes them off the edge of their map:
A: Can you think of any alternative to charging fines for overdue books?
S: I'm not sure there is one.
A: Pretend there is – what might it be?
S: Well... I suppose we could just freeze their library account... I suppose we could notify their tutors, at least for students. That wouldn't work for staff or alumni, however.
The point here is not necessarily to get a definitive answer or strategy (although that would be nice), but rather to get the stakeholder thinking out of the box, to use their imagination, and to see that there might be territory beyond the edges of their current map and possibilities that they might not yet have considered. Note that Pretend there is – what might it be? is a hypnotic language pattern because we invite the stakeholder to direct their attention internally and use their imagination. In Generative Analysis, we define a meta language called Milton++, that presents a useful set of these patterns.
Another use of Why is to extend an existing map of reality to identify the root cause of a problem. This is called use root cause analysis, also known as the "5 Whys". It was invented by Sakichi Toyoda, the founder of Toyota industries, and it aims to find the ultimate cause of a problem by asking Why five times. It has been successfully applied within Toyota since the 1930s. The process is simple:
- Identify the problem – the focus of the 5 Why questions.
- Ask Why to find the first reason.
- Ask Why to find the second reason.
- Ask Why 3 more times (5 times in total) if you can.
This is based on the observation that the initial "reason" given for a problem is often just a symptom of a deeper underlying problem. At some point in the chain of 5 Why Questions, we hope to exhaust the symptoms of the problem and get to an answer that is the "root cause". In terms of the map and the territory metaphor, we need to use Why to extend the map until it includes the root cause of the problem. We need to embrace the dragons.
In practice, note that 5 is not a magic number, it is just that asking Why five times is usually enough to get to the root cause. If you must ask Why more times, then so be it. If you think you have got to the root cause in fewer than five Whys, this might be perfectly OK but be careful that you haven't stopped the questioning too soon.
Here is an example of root cause analysis loosely based on a real interaction with a client (note that we use six Whys):
S: The server always likes to be rebooted every day or so.
A: Why does the server always like to be rebooted every day or so?
S: It just fills up with crud, and the reboot cleans it out.
A: Why does it fill up with crud?
S: There's an error log file that fills up and rebooting deletes it.
A: Why does the log file fill up?
S: The system generates a lot of errors I suppose.
A: Why is the system generating errors?
S: I'll take a look... (opens the log file)... It appears to be a stream of errors coming out of the Security subsystem.
A: Why is there a stream of errors coming out of the Security subsystem?
S: We'll need to have a look at the code to find out... (sometime later)... Got it! There are two other subsystems each using the Security subsystem to authenticate the same user.
A: Why are two different subsystems trying to authenticate the same user?
S: They shouldn't be! Only the first subsystem needs to authenticate the user, the other subsystem needs to check that the user was authenticated, but not try to authenticate them itself. When the user is already authenticated, the second subsystem fails and logs an error. That's the problem - we need to fix this!
In the original map, the server had the anthropomorphic quality that it "liked" to be rebooted every day or so. This is a clear indication of a map that does not accord with the territory very well, because servers have no "likes" or "dislikes". We need to either extend or replace the map to make it accord with reality and we extend it using Why Questions as shown.