Eight to Late

Sensemaking and Analytics for Organizations

Beyond words: visualising arguments using issue maps

with 16 comments

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

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

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

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

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

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.

16 Responses

Subscribe to comments with RSS.

  1. Brillaint work again mate. Damn! What have I created here?? 🙂

    I’m just going to pick on one flaw in your IBIS form :-). Ideas are the only things that repond to issues, so the con “Does not help in software design” should not link to the question “Are there any promising approaches…” question. You need to add another idea in between the con and the question.

    Aside from that your IBIS is bloody excellent!


    Paul Culmsee

    May 1, 2009 at 2:16 am

  2. Paul,

    Thanks for your feedback.

    My understanding is that any type of node – question, idea or argument – can be questioned, as shown in Fig 2 of this paper. Hence my depiction of the question “Are there any promising approaches…” as a response to the argument “Does not help in…”

    Thanks again for taking the time to read my post and providing feedback – I truly appreciate it.





    May 1, 2009 at 7:56 pm

  3. Ah sorry mate your completely right. i was reading the map from left to right and the vertical orientation threw me off and I read the arrow in reverse.

    One thing that its good to do is to be careful when you group cons. Often the resulting argumentation after a con against a bunch of ideas will be just for one of these ideas, so you will have to refactor the maps.

    Also draw a basic map and then do a Control+R for auto resizing and repositioning of your nodes. I almost always go left to right personally. I’ll send you a couple of good samples if you like…




    Paul Culmsee

    May 2, 2009 at 1:43 am

    • p.s the same warning above applies to any node. Its not a rule but does improve readability.


      Paul Culmsee

      May 2, 2009 at 1:44 am

  4. […] who has laboured through a piece of reasoning in prose form is familiar with this problem.  In an earlier post I discussed, via example, the utility of issue mapping – a visual representation of reasoning […]


  5. […] Eight to Late von Kailash Awati (Australien) gestoßen. Er hat sich in einem initialen Posting der Visualisierung von Diskussionen durch Issue Maps […]


  6. […] experience with IBIS is to use it to create issue maps of arguments presented in articles.  See this post for an example of an issue map based on Fred Brooks’ classic article, No Silver […]


  7. […] experience with IBIS is to use it to create issue maps of arguments presented in articles.  See this post for an example of an issue map based on Fred Brooks’ classic article, No Silver […]


  8. […] essential problem of software design – figuring out what the software really needs to do (see this post for more on Brooks’ argument). Well designed software embodies both kinds of knowledge, so […]


  9. […] into prose, wherefrom it can be hard to pick out the essential thread of argumentation.  In an earlier post I showed how an issue map can help in clarifying the central arguments in a “difficult” piece […]


  10. […] diagram represents an essential grammar of IBIS – as simple as that.  See this post or this one for examples of the use of IBIS in visualizing arguments that are in prose […]


  11. […] See this post and this one for examples of  how IBIS can be used to visualise written […]


  12. […] this post or this one for examples of argument visualisation (issue mapping) using […]


  13. […] See this postor this one for examples of argument visualisation. (Note: using IBIS to map out the structure of written arguments is called issue mapping. […]


  14. […] other ways in which IBIS can be used, that do not require as much skill. Some of these include: mapping the central points in written arguments (what’s sometimes called issue mapping) and even decisions on personal […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: