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:

1. It deals with issues that most software developers have grappled with at one time or another.
2. 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:

1. By examining the nature of the essential (intrinsic or inherent) difficulties in developing software.
2. 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.