Archive for the ‘Design Rationale’ Category
Making sense of sensemaking – the dimensions of participatory design rationale
Introduction
Over the last year or so, I’ve used IBIS (Issue-Based Information System) to map a variety of discussions at work, ranging from design deliberations to project meetings [Note: see this post for an introduction to IBIS and this one for an example of mapping dialogues using IBIS]. Feedback from participants indicated that IBIS helps to keep the discussion focused on the key issues, thus leading to better outcomes and decisions. Some participants even took the time to learn the notation (which doesn’t take long) and try it out in their own meetings. Yet, despite their initial enthusiasm, most of them gave it up after a session or two. Their reasons are well summed up by a colleague who said, “It is just too hard to build a coherent map on the fly while keeping track of the discussion.”
My colleague’s comment points to a truth about the technique: the success of a sense-making session depends rather critically on the skill of the practitioner. The question is: how do experienced practitioners engage their audience and build a coherent map whilst keeping the discussion moving in productive directions? Al Selvin, Simon Buckingham-Shum and Mark Aakhus provide a part answer to this question in their paper entitled, The Practice Level in Participatory Design Rationale : Studying Practitioner Moves and Choices. Specifically, they describe a general framework within which the practice of participatory design rationale (PDR) can be analysed (Note: more on PDR in the next section). This post is a discussion of some aspects of the framework and some personal reflections based on my (limited) experience.
A couple of caveats are in order before I proceed. Firstly, my discussion focuses on understanding the dimensions (or variables) that describe the act of creating design representations in real-time. Secondly, my comments and reflections on the model are based on my experiences with a specific design rationale technique – IBIS.
Background
First up, it is worth clarifying the meaning of participatory design rationale (PDR). The term refers to the collective reasoning behind decisions that are made when a group designs an artifact. Generally such rationale involves consideration of various alternatives and why they were or weren’t chosen by the group. Typically this involves several people with differing views. Participatory design is thus an argumentative process, often with political overtones.
Clearly, since design involves deliberation and may also involve a healthy dose of politics, the process will work more effectively if it is structured. The structure should, however, be flexible: it must not constrain the choices and creativity of those involved. This is where the notation and practitioner (facilitator) come in: the notation lends structure to the discussion and the practitioner keeps it going in productive directions, yet in a way that sustains a coherent narrative. The latter is a creative process, much like an art. The representation (such as IBIS) – through its minimalist notation and grammar – helps keep the key issues, ideas and arguments firmly in focus. As Selvin noted in an earlier paper, this encourages collective creativity because it forces participants to think through their arguments more carefully than they would otherwise. Selvin coined the term knowledge art to refer to this process of developing and engaging with design representations. Indeed, the present paper is a detailed look at how practitioners create knowledge art – i.e. creative, expressive representations of the essence of design discussions. Quoting from the paper:
…we are looking at the experience of people in the role of caretakers or facilitators of such events – those who have some responsibility for the functioning of the group and session as a whole. Collaborative DR practitioners craft expressive representations on the fly with groups of people. They invite participant engagement, employing techniques like analysis, modeling, dialogue mapping, creative exploration, and rationale capture as appropriate. Practitioners inhabit this role and respond to discontinuities with a wide variety of styles and modes of action. Surfacing and describing this variety are our interests here.
The authors have significant experience in leading deliberations using IBIS and other design rationale methods. They propose a theoretical framework to identify and analyse various moves that practitioners make in order to keep the discussion moving in productive direction. They also describe various tools that they used to analyse discussions, and specific instances of the use of these tools. In the remainder of this post, I’ll focus on their theoretical framework rather than the specific case studies, as the former (I think) will be of more interest to readers. Further, I will focus on aspects of the framework that pertain to the practice – i.e. the things the practitioner does in order to keep the design representation coherent, the participants engaged and the discussion useful, i.e. moving in productive directions.
The dimensions of design rationale practice
So what do facilitators do when they lead deliberations? The key actions they undertake are best summed up in the authors’ words:
…when people act as PDR practitioners, they inherently make choices about how to proceed, give form to the visual and other representational products , help establish meanings, motives, and causality and respond when something breaks the expected flow of events , often having to invent fresh and creative responses on the spot.
This sentence summarises the important dimensions of the practice. Let’s look at each of the dimensions in brief:
- Ethics: At key points in the discussion, the practitioner is required to make decisions on how to proceed. These decisions cannot (should not!) be dispassionate or objective (as is often assumed), they need to be made with due consideration of “what is good and what is not good” from the perspective of the entire group.
- Aesthetics: This refers to the representation (map) of the discussion. As the authors put it, “All diagrammatic DR approaches have explicit and implicit rules about what constitutes a clear and expressive representation. People conversant with the approaches can quickly tell whether a particular artifact is a “good” example. This is the province of aesthetics.” In participatory design, representations are created as the discussion unfolds. The aesthetic responsibility of the practitioner is to create a map that is syntactically correct and expressive. Another aspect of the aesthetic dimension is that a “beautiful” map will engage the audience, much like a work of art.
- Narrative: One of the key responsibilities of the practitioner is to construct a coherent narrative from the diverse contributions made by the participants. Skilled practitioners pick up connections between different contributions and weave these into a coherent narrative. That said, the narrative isn’t just the practitioner’s interpretation; the practitioner has to ensure that everyone in the group is happy with the story; the story is to the group’ s story. A coherent narrative helps the group make sense of the discussion: specifically the issues canvassed, ideas offered and arguments for and against each of them. Building such a narrative can be challenging because design discussions often head off in unexpected directions.
- Sensemaking: During deliberations it is quite common that the group gets stuck. Progress can be blocked for a variety of reasons ranging from a lack of ideas on how to make progress to apparently irreconcilable differences of opinion on the best way to move forward. At these junctures the role of the practitioner is to break the impasse. Typically this involves conversational moves that open new ground (not considered by the group up to that point) or find ways around obstacles (perhaps by suggesting compromises or new choices). The key skill in sensemaking is the ability to improvise, which segues rather nicely into the next variable.
- Improvisation: Books such as Jeff Conklin’s classic on dialogue mapping describe some standard moves and good practices in PDR practice. In reality, however, a practitioner will inevitably encounter situations that cannot be tackled using standard techniques. In such situations the practitioner has to improvise. This could involve making unconventional moves within the representation or even using another representation altogether. These improvisations are limited only by the practitioner’s creativity and experience.
Using case studies, the authors illustrate how design rationale sessions can be analysed along the aforementioned dimensions, both at a micro and macro level. The former involves a detailed move-by-move study of the session and the latter an aggregated view, based on the overall tenor of episodes consisting of several moves. I won’t say any more about the analyses here, instead I’ll discuss the relevance of the model to the actual practice of design rationale techniques such as dialogue mapping.
Some reflections on the model
When I first heard about dialogue mapping, I felt the claims made about the technique were exaggerated: it seemed impossible that a simple notation like IBIS (which consists of just three elements and a simple grammar) could actually enhance collaboration and collective creativity of a group. With a bit of experience, I began to see that it actually did do what it claimed to do. However, I was unable to explain to others how or why it worked. In one conversation with a manager, I found myself offering hand-waving explanations about the technique – which he (quite rightly) found unconvincing. It seemed that the only way to see how or why it worked was to use it oneself. In short: I realised that the technique involved tacit rather than explicit knowledge.
Now, most practices– even the most mundane ones – involve a degree of tacitness. In fact, in an earlier post I have argued that the concept of best practice is flawed because it assumes that the knowledge involved in a practice can be extracted in its entirety and codified in a manner that others can understand and reproduce. This assumption is incorrect because the procedural aspects of a practice (which can be codified) do not capture everything – they miss aspects such as context and environmental influences, for instance. As a result a practice that works in a given situation may not work in another, even though the two may be similar. So it is with PDR techniques – they work only when tailored on the fly to the situation at hand. Context is king. In contrast the procedural aspects of PDR techniques– syntax, grammar etc – are trivial and can be learnt in a short time.
In my opinion, the value of the model is that it attempts to articulate tacit aspects of PDR techniques. In doing so, it tells us why the techniques work in one particular situation but not in another. How so? Well, the model tells us the things that PDR practitioners worry about when they facilitate PDR sessions – they worry about the form of the map (aesthetics), the story it tells (narrative), helping the group resolve difficult issues (sensemaking), making the right choices (ethics) and stepping outside the box if necessary (improvisation). These are tacit skills- they can’t be taught via textbooks, they can only be learnt by doing. Moreover, when such techniques fail the reason can usually be traced back to a failure (of the facilitator) along one or more of these dimensions.
Wrapping up
Techniques to capture participatory design rationale have been around for a while. Although it is generally acknowledged that such techniques aid the process of collaborative design, it is also known that their usefulness depends rather critically on the skill of the practitioner. This being the case, it is important to know what exactly skilled practitioners do that sets them apart from novices and journeymen. The model is a first step towards this. By identifying the dimensions of PDR practice, the model gives us a means to analyse practitioner moves during PDR sessions – for example, one can say that this was a sensemaking move or that was an improvisation. Awareness of these types of moves and how they work in real life situations can help novices learn the basics of the craft and practitioners master its finer points.
The what and whence of issue-based information systems
Over the last few months I’ve written a number of posts on IBIS (short for Issue Based Information System), an argument visualisation technique invented in the early 1970s by Horst Rittel and Werner Kunz. IBIS is best known for its use in dialogue mapping – a collaborative approach to tackling wicked problems – but it has a range of other applications as well (capturing project knowledge is a good example). All my prior posts on IBIS focused on its use in specific applications. Hence the present piece, in which I discuss the “what” and “whence” of IBIS: its practical aspects – notation, grammar etc. – along with its origins, advantages and limitations
I’ll begin with a brief introduction to the technique (in its present form) and then move on to its origins and other aspects.
A brief introduction to IBIS
IBIS consists of three main elements:
- Issues (or questions): these are issues that need to be addressed.
- Positions (or ideas): these are responses to questions. Typically the set of ideas that respond to an issue represents the spectrum of perspectives on the issue.
- Arguments: these can be Pros (arguments supporting) or Cons (arguments against) an issue. The complete set of arguments that respond to an idea represents the multiplicity of viewpoints on it.
The best IBIS mapping tool is Compendium – it can be downloaded here. In Compendium, the IBIS elements described above are represented as nodes as shown in Figure 1: issues are represented by green question nodes; positions by yellow light bulbs; pros by green + signs and cons by red – signs. Compendium supports a few other node types, but these are not part of the core IBIS notation. Nodes can be linked only in ways specified by the IBIS grammar as I discuss next.
Figure 1: IBIS Elements
The IBIS grammar can be summarized in a few simple rules:
- Issues can be raised anew or can arise from other issues, positions or arguments. In other words, any IBIS element can be questioned. In Compendium notation: a question node can connect to any other IBIS node.
- Ideas can only respond to questions – i.e. in Compendium “light bulb” nodes can only link to question nodes. The arrow pointing from the idea to the question depicts the “responds to” relationship.
- Arguments can only be associated with ideas – i.e in Compendium + and – nodes can only link to “light bulb” nodes (with arrows pointing to the latter)
The legal links are summarized in Figure 2 below.
Figure 2: Legal Links in IBIS
The rules are best illustrated by example- follow the links below to see some illustrations of IBIS in action:
- See this post for a simple example of dialogue mapping.
- See this post or this one for examples of argument visualisation .
- See this post for the use IBIS in capturing project knowledge.
Now that we know how IBIS works and have seen a few examples of it in action, it’s time to trace its history from its origins to the present day.
Wicked origins
A good place to start is where it all started. IBIS was first described in a paper entitled, Issues as elements of Information Systems; written by Horst Rittel (who coined the term “wicked problem”) and Werner Kunz in July 1970. They state the intent behind IBIS in the very first line of the abstract of their paper:
Issue-Based Information Systems (IBIS) are meant to support coordination and planning of political decision processes. IBIS guides the identification, structuring, and settling of issues raised by problem-solving groups, and provides information pertinent to the discourse.
Rittel’s preoccupation was the area of public policy and planning – which is also the context in which he defined wicked problems originally. He defined the term in his landmark paper of 1973 entitled, Dilemmas in a General Theory of Planning. A footnote to the paper states that it is based on an article that he presented at an AAAS meeting in 1969. So it is clear that he had already formulated his ideas on wickedness when he wrote his paper on IBIS in 1970.
Given the above background it is no surprise that Rittel and Kunz foresaw IBIS to be the:
…type of information system meant to support the work of cooperatives like governmental or administrative agencies or committees, planning groups, etc., that are confronted with a problem complex in order to arrive at a plan for decision…
The problems tackled by such cooperatives are paradigm-defining examples of wicked problems. From the start, then, IBIS was intended as a tool to facilitate a collaborative approach to solving such problems.
Operation of early systems
When Rittel and Kunz wrote their paper, there were three IBIS-type systems in operation: two in governmental agencies (in the US, one presumes) and one in a university environment (possibly, Berkeley, where Rittel worked). Although it seems quaint and old-fashioned now, it is no surprise that they were all manual, paper-based systems- the effort and expense involved in computerizing such systems in the early 70s would have been prohibitive, and the pay-off questionable.
The paper also offers a short description of how these early IBIS systems operated:
An initially unstructured problem area or topic denotes the task named by a “trigger phrase” (“Urban Renewal in Baltimore,” “The War,” “Tax Reform”). About this topic and its subtopics a discourse develops. Issues are brought up and disputed because different positions (Rittel’s word for ideas or responses) are assumed. Arguments are constructed in defense of or against the different positions until the issue is settled by convincing the opponents or decided by a formal decision procedure. Frequently questions of fact are directed to experts or fed into a documentation system. Answers obtained can be questioned and turned into issues. Through this counterplay of questioning and arguing, the participants form and exert their judgments incessantly, developing more structured pictures of the problem and its solutions. It is not possible to separate “understanding the problem” as a phase from “information” or “solution” since every formulation of the problem is also a statement about a potential solution.
Even today, forty years later, this is an excellent description of how IBIS is used to facilitate a common understanding of complex (or wicked) problems. The paper contains an overview of the structure and operation of manual IBIS-type systems. However, I’ll omit these because they are of little relevance in the present-day world.
As an aside, there’s a term that’s conspicuous by its absence in the Rittel-Kunz paper: design rationale. Rittel must have been aware of the utility of IBIS in capturing design rationale: he was a professor of design science at Berkley and design reasoning was one of his main interests. So it is somewhat odd that he does not mention this term even once in his IBIS paper.
Fast forward a couple decades (and more!)
In a paper published in 1988 entitled, gIBIS: A hypertext tool for exploratory policy discussion, Conklin and Begeman describe a prototype of a graphical, hypertext-based IBIS-type system (called gIBIS) and its use in capturing design rationale (yes, despite the title of the paper, it is more about capturing design rationale than policy discussions). The development of gIBIS represents a key step between the original Rittel-Kunz version of IBIS and its present-day version as implemented in Compendium. Amongst other things, IBIS was finally off paper and on to disk, opening up a new world of possibilities.
gIBIS aimed to offer users:
- The ability to capture design rationale – the options discussed (including the ones rejected) and the discussion around the pros and cons of each.
- A platform for promoting computer-mediated collaborative design work – ideally in situations where participants were located at sites remote from each other.
- The ability to store a large amount of information and to be able to navigate through it in an intuitive way.
Before moving on, one point needs to be emphasized: gIBIS was intended to be used in collaborative settings; to help groups achieve a shared understanding of central issues, by mapping out dialogues in real time. In present-day terms – one could say that it was intended as a tool for sense making.
The gIBIS prototype proved successful enough to catalyse the development of Questmap, a commercially available software tool that supported IBIS. However, although there were some notable early successes in the real-time use of IBIS in industry environments (see this paper, for example), these were not accompanied by widespread adoption of the technique. Other graphical, IBIS-like methods to capture design rationale were proposed (an example is Questions, Options and Criteria (QOC) proposed by MacLean et. al. in 1991), but these too met with a general reluctance in adoption.
Making sense through IBIS
The reasons for the lack of traction of IBIS-type techniques in industry are discussed in an excellent paper by Shum et. al. entitled, Hypermedia Support for Argumentation-Based Rationale: 15 Years on from gIBIS and QOC. The reasons they give are:
- For acceptance, any system must offer immediate value to the person who is using it. Quoting from the paper, “No designer can be expected to altruistically enter quality design rationale solely for the possible benefit of a possibly unknown person at an unknown point in the future for an unknown task. There must be immediate value.” Such immediate value is not obvious to novice users of IBIS-type systems.
- There is some effort involved in gaining fluency in the use of IBIS-based software tools. It is only after this that users can gain an appreciation of the value of such tools in overcoming the limitations of mapping design arguments on paper, whiteboards etc.
The intellectual effort – or cognitive overhead, as it is called in academese – in using IBIS in real time involves:
- Teasing out issues, ideas and arguments from the dialogue.
- Classifying points raised into issues, ideas and arguments.
- Naming (or describing) the point succinctly.
- Relating (or linking) the point to an existing node.
This is a fair bit of work, so it is no surprise that beginners might find it hard to use IBIS to map dialogues. However, once learnt, a skilled practitioner can add value to design (and more generally, sense making) discussions in several ways including:
- Keeping the map (and discussion) coherent and focused on pertinent issues.
- Ensuring that all participants are engaged in contributing to the map (and hence the discussion).
- Facilitating useful maps (and dialogues) – usefulness being measured by the extent to which the objectives of the session are achieved.
See this paper by Selvin and Shum for more on these criteria. Incidentally, these criteria are a qualitative measure of how well a group achieves a shared understanding of the problem under discussion. Clearly, there is a good deal of effort involved in learning and becoming proficient at using IBIS-type systems, but the payoff is an ability to facilitate a shared understanding of wicked problems – whether in public planning or in technical design.
Why IBIS is better than conventional modes of documentation
IBIS has several advantages over conventional documentation systems. Rittel and Kunz’s 1970 paper contains a nice summary of the advantages, which I paraphrase below:
- IBIS can bridge the gap between discussions and records of discussions (minutes, audio/video transcriptions etc,). IBIS sits between the two, acting as a short term memory. The paper thus foreshadows the use of issue-based systems as an aid to organizational or project memory.
- Many elements (issue, ideas or arguments) that come up in a discussion have contextual meanings that are different from any pre-existing definitions. In discussions, contextual meaning is more than formal meaning. IBIS captures the former in a very clear way – for example a response to a question “What do we mean by X? elicits the meaning of X in the context of the discussion, which is then subsequently captured as an idea (position)”.
- Related to the above, the commonality of an issue with other, similar issues might be more important than its precise meaning. To quote from the paper, “…the description of the subject matter in terms of librarians or documentalists (sic) may be less significant than the similarity of an issue with issues dealt with previously and the information used in their treatment…” With search technologies available, this is less of an issue now. However, search technologies are still limited in terms of finding matches between “similar” items (How is “similar” defined? Ans: it depends on context). A properly structured, context-searchable IBIS-based project archive may still be more useful than a conventional document archive based on a document management system.
- The reasoning used in discussions is made transparent, as is the supporting (or opposing) evidence. (see my post on visualizing argumentation for example)
- The state of the argument (discussion) at any time can be inferred at a glance (unlike the case in written records). See this post for more on the advantages of visual documentation over prose.
Issues with issue-based information systems
Lest I leave readers with the impression that IBIS is a panacea, I should emphasise that it isn’t. According to Conklin, IBIS maps have the following limitations:
- They atomize streams of thought into unnaturally small chunks of information thereby breaking up any smooth rhetorical flow that creates larger, more meaningful chunks of narrative.
- They disperse rhetorically connected chunks throughout a large structure.
- They are not is not chronological in structure (the chronological sequence is normally factored out);
- Contributions are not attributed (who said what is normally factored out).
- They do not convey the maturity of the map – one cannot distinguish, from the map alone, whether one map is more “sound” than another.
- They do not offer a systematic way to decide if two questions are the same, or how the maps of two related questions relate.
Some of these issues (points 3, 4) can be addressed by annotating nodes; others are not so easy to solve.
Concluding remarks
My aim in this post has been to introduce readers to the IBIS notation, and also discuss its origins, development and limitations. On one hand, a knowledge of the origins and development is valuable because it gives insight into the rationale behind the technique, which leads to a better understanding of the different ways in which it can be used. On the other, it is also important to know a technique’s limitations, if for no other reason than to be aware of these so that one can work around them.
Before signing off, I’d like to mention an observation from my experience with IBIS. The real surprise for me has been that the technique can capture most written arguments and discussions, despite having only three distinct elements and a very simple grammar. Yes, it does require some thought to do this, particularly when mapping discussions in real time. However, this cognitive “overhead” is good because it forces the mapper to think about what’s being said instead of just writing it down blind. Thoughtful transcription is the aim of the game. When done right, this results in a map that truly reflects a shared understanding of the complex (and possibly wicked) problem under discussion.
There’s no better coda to this post on IBIS than the following quote from this paper by Conklin:
…Despite concerns over the years that IBIS is too simple and limited on the one hand or too hard to use on the other, there is a growing international community who are fluent enough in IBIS to facilitate and capture highly contentious debates using dialogue mapping, primarily in corporate and educational environments…
For me that’s reason enough to improve my understanding of IBIS and its applications, and to look for opportunities to use it in ever more challenging situations.
Beyond words: visualising arguments using issue maps
Anyone who has struggled to follow a complex argument in a book or article knows from experience that reasoning in written form can be hard to understand. Perhaps this is why many people prefer to learn by attending a class or viewing a lecture rather than by reading. The cliché about a picture being worth more than a large number of words has a good deal of truth to it: visual representations can be helpful in clarifying complex arguments. In a recent post, I presented a quick introduction to a visual issue mapping technique called IBIS (Issue Based Information System), discussing how it could be used on complex projects. Now I follow up by demonstrating its utility in visualising complex arguments such as those presented in research papers. I do so by example: I map out a well known opinion piece written over two decades ago – Fred Brooks’ classic article, No Silver Bullet, (abbreviated as NSB in the remainder of this article).
[Note: those not familiar with IBIS may want to read one of the introductions listed here before proceeding]
Why use NSB as an example for argument mapping? Well, for a couple of reasons:
- It deals with issues that most software developers have grappled with at one time or another.
- The piece has been widely misunderstood (by Brooks’ own admission – see his essay entitled No Silver Bullet Refired, published in the anniversary edition of The Mythical Man Month).
First, very briefly, for those who haven’t read the article: NSB presents reasons why software development is intrinsically hard and consequently conjectures that “silver bullet” solutions are impossible, even in principle. Brooks defines a silver bullet solution for software engineering as any tool or technology that facilitates a tenfold improvement in productivity in software development.
To set the context for the discussion and to see the angle from which Brooks viewed the notion of a silver bullet for software engineering, I can do no better than quote the first two paragraphs of NSB:
Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest.
The familiar software project, at least as seen by the non-technical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet—something to make software costs drop as rapidly as computer hardware costs do.
The first step in mapping out an argument is to find the basic issue that it addresses. That’s easy for NSB; the issue, or question, is: why is there no silver bullet for software development?
Brooks attempts to answer the question via two strands:
- By examining the nature of the essential (intrinsic or inherent) difficulties in developing software.
- By examining the silver bullet solutions proposed so far.
That gives us enough for us to begin our IBIS map …
Issue Map – Stage 1
The root node of the map – as in all IBIS maps – is a question node. Responding to the question, we have an idea node (Essential difficulties) and another question node (What about silver bullet solutions proposed to date). We also have a note node which clarifies what is meant by a silver bullet solution.
The point regarding essential difficulties needs elaboration, so we ask the question– What are essential difficulties?
According to Brooks, essential difficulties are those that relate to conceptualisation – i..e. design. In contrast, accidental (or non-essential) difficulties are those pertaining to implementation. Brooks examines the nature of essential difficulties – i.e. the things that make software design hard. He argues that the following four properties of software systems are the root of the problem:
Complexity: Beyond the basic syntax of a language, no two parts of a software system are alike – this contrasts with other products (such as cars or buildings) where repeated elements are common. Furthermore, software has a large number of states, multiplied many-fold by interactions with other systems. No person can fully comprehend all the consequences of this complexity. Furthermore, no silver bullet solution can conquer this problem because each program is complex in unique ways.
Conformity: Software is required to conform to arbitrary business rules. Unlike in the natural sciences, these rules may not (often do not!) have any logic to them. Further, being the newest kid on the block, software often has to interface with disparate legacy systems as well. Conformity-related issues are external to the software and hence cannot be addressed by silver bullet solutions.
Changeability: Software is subject to more frequent change than any other part of a system or even most other manufactured products. Brooks speculates that this is because most software embodies system functionality (i.e. the way people use the system), and functionality is subject to frequent change. Another reason is that software is intangible (made of “thought stuff”) and perceived as being easy to change.
Invisibility: Notwithstanding simple tools such as flowcharts and modelling languages, Brooks argues that software is inherently unvisualisable. The basic reason for this is that software – unlike most products (cars, buildings, silicon chips, computers) – has no spatial form.
These essential properties are easily captured in summary form in our evolving argument map:
Issue Map – Stage 2
Brooks’ contention is that software design is hard because every software project has to deal with unique manifestations of these properties.
Brooks then looks at silver bullet solutions proposed up to 1987 (when the article was written) and those on the horizon at the time. He finds most of these address accidental (or non-intrinsic) issues – those that relate to implementation rather than design. They enhance programmer productivity – but not by the ten-fold magnitude required for them to be deemed silver bullets. Brooks reckons this is no surprise: the intrinsic difficulties associated with design are by far the biggest obstacles in any software development effort.
In the map I club all these proposed solutions under “silver bullet solutions proposed to date.”
Incorporating the above, the map now looks like:
Issue Map – Stage 3
[For completeness here’s a glossary of abbreviations: OOP – Object-oriented programming; IDE – Integrated development environment; AI – Artificial intelligence]
The proposed silver bullets lead to incremental improvements in productivity, but they do not address the essential problem of design. Further, some of the solutions have restricted applicability. These points are captured as pros and a cons in the map (click on the map to view a larger image):
Issue Map – Stage 4
It is interesting to note that in his 1997 article, No Silver Bullet Refired , which revisited the questions raised in NSB, Brooks found that the same conclusions held true. Furthermore, at a twentieth year retrospective panel discussion that took place during the 22nd International Conference on Object-Oriented Programming, Systems, Languages, and Applications, panellists again concluded that there’s no silver bullet – and none likely.
Having made his case that no silver bullet exists, and that none are likely, Brooks finishes up by outlining a few promising approaches to tackling the design problem. The first one, Buy don’t build, is particularly prescient in view of the growth of the shrink-wrapped software market in the two decades since the first publication of NSB. The second one – rapid prototyping and iterative/incremental development – is vindicated by the widespread adoption and mainstreaming of agile methodologies. The last one, nurture talent, perhaps remains relatively ignored. It should be noted that Brooks considers these approaches promising, but not silver bullets; he maintains that none of these by themselves can lead to a tenfold increase in productivity.
So we come to the end of NSB and our map, which now looks like (click on the map to view a larger image):
Final Map
The map captures the essence of the argument in NSB – a reader can see, at a glance, the chain of reasoning and the main points made in the article. One could embellish the map and improve readability by:
- Adding in details via note nodes, as I have done in my note explaining what is meant by a silver bullet.
- Breaking up the argument into sub-maps – the areas highlighted in yellow in each of the figures could be hived off into their own maps.
But these are details; the essence of the argument in NSB is captured adequately in the final map above.
In this post I have attempted to illustrate, via example, the utility of IBIS in constructing maps of complicated arguments. I hope I’ve convinced you that issue maps offer a simple way to capture the essence of a written argument in an easy-to-understand way.
Perhaps the cliche should be revised: a picture may be worth a thousand words, but an issue map is worth considerably more.
IBIS References on the Web
For a quick introduction, I recommend Jeff Conklin’s introduction to IBIS on the Cognexus site (and the links therein) or my piece on the use of IBIS in projects. If you have some time, I highly recommend Paul Culmsee’s excellent series of posts: the one best practice to rule them all.
Eight to Late 