Column for the Automated Software
Engineering journal
The original publication is available at
www.springerlink.com
"You are
marooned on a desert island with only a handful of books
and/or papers relating to software engineering at your disposal.
Which books or papers should those be?
They may be seminal, thought-provoking or simply a pleasure to read."
The challenge is typical of software specifications: it is written in natural language; it is precise where one might wish it vague, open-ended where one might wish it definitive; it contains rich scope for ambiguity; it is suggestive and human; it hints at stakeholders in a very different world from the reader; and meeting the challenge in full would take an undefinable amount of effort. Meanwhile, the audience would like to hear about some books they themselves have not read.
Clearly, however, assumptions in western culture about the ‘desert island’ can be adopted. If the island were really desert, and one only had books and papers to survive on, there would be at most a few hours for reading before dehydration supervened. So the frame includes food, fresh water and some kind of shelter from tropical storms to protect the reading matter and the reader, while exercise in the form of swimming is safe enough from sharks: perhaps the island has a fringing coral reef.
Another aspect of the island domain is the purpose of reading while there. If rescue is unlikely, then the reading is for personal enjoyment, not to stimulate writing for publication. This at once sets software engineering against great literature: islanders would not choose to be marooned with technical materials that make sense only in the context of computational hardware and a supply of electricity. Therefore, the books or papers must be durable and able to stand alone. Bob Dylan once said “a song is anything that walks by itself” – an odd definition, but you can see what he meant. I hope, by the way, that I would be allowed to take a guitar and a good supply of sheet music for it to my island, including some of Dylan’s best songs for acoustic guitar.
Durability is a problematic attribute. Some excellent books can give the reader a flash of insight which endures, permanently changing one’s attitude or adding a new conceptual tool: yet, once assimilated, there is little reason for the book to be re-read. Al Davis’ book on triage, Just Enough Requirements Management, for instance, (Dorset House, 2005) thus makes it to the doorstep of the Desert Island but no further.
The Castaway, then, wants to take along books that provide enduring solace and stimulation.
The original Desert Island castaways of Roy Plomley’s BBC Radio 4 programme were allowed the Bible and the Collected Works of Shakespeare by default: both because these are excellent choices for a long stay, and to prevent castaways from escaping their responsibilities in these directions.
A really long novel like Tolstoy’s War and Peace, or Tolkien’s Lord of the Rings, is also a tempting choice, but such books can only be related to software engineering by the most sophistical of arguments.
Donald Knuth’s The Art of Computer Programming: Volumes 1-3 (and fascicles of Volume 4: will the set ever be finished?) is similarly an obvious choice for the list of things one has always put off reading but assumes to be ideal for a long stay. Knuth is therefore presumably already included in the Island’s welcome pack, along with the machete, the fish-hooks and the fire-lighting kit: in other words, forbidden for inclusion in The List.
Firstly, then, I would like to learn something completely new on the island. The time-honoured advice to authors wishing to write on any technical subject was to write for a geologist: someone intelligent, qualified in their own domain, but uninformed about the subject. On my island, which I hope is a peacefully active volcano (in the manner of Kilauea), I would therefore like to return the compliment by studying Schmincke’s superb Volcanism in detail. I would wander the island with a hammer to collect samples and make notes, before returning to my palm-leaf shelter to try to work out what I had found. Schmincke is clearly a total enthusiast for his tumultuous subject. The book is filled with beautiful maps, diagrams, graphs, and photographs of specimens at every scale from microscopic to mountainous. The captions are a delight in themselves:
“Photomicrograph of a strongly welded Miocene compositionally zoned (trachytic-basaltic) ignimbrite. The light-coloured crystals are feldspars, the blue crystal is amphibole, and the brownish irregular particles are glassy fiamme, strongly deformed when deposited hot.”
The description is simultaneously captivating, clear, instructive, and unashamedly technical. Now, if I could only write like that...
Next, I’d take something by Checkland, such as Soft Systems Methodology in Action. Every system has both ‘hard’ and ‘soft’ aspects – systems can be arranged on a scale of soft-to-hard, which seems to correlate both with early-to-late and with high-level (big-picture) to low-level. SSM is special in paying attention to how to do things better, including itself; and in insisting on looking at the meanings people give to things, rather than treating systems as abstract entities. SSM has thus been swimming against the tide of modelling languages and ignorance for many years. The early 20th century British journalist and novelist G. K. Chesterton once said that if there was an idea in the news that everyone assumed was obvious, the right thing to do was to assume the opposite, and to see where that led you. SSM is very much “the opposite” of the assumption that technology is the solution, no matter that you don’t have any clear idea of the problem. Like everyone else, I have dipped into SSM, and even tried to help people to think about stakeholders: it would be nice to settle down and think through each concept and analysis in detail.
“When the miner strikes gold, he throws away his tools”. Something very impressive happens when a mathematician realises that the essence of a subject is not equations but sharply-defined thought. James Dewar directs one of RAND’s centres, and has written something really wonderful in his Assumption-Based Planning. Like the very best ideas, it is simple but subtle: so obvious that you feel you could have thought of it yourself, but deep in the sense that it is based on many years of experience and reflection. It is immediately practical, and leads to a range of straightforward recommendations for projects to follow. It is however strongly grounded in theory, so its suggestions are robust – all the more striking that they are qualitative. It led me to the realisation that one could treat (and diagram) any kind of argumentation using chains of assumptions: facts, conclusions, warrants, rebuttals and pieces of supporting evidence (yes, I admire Stephen Toulmin’s The Uses of Argument) are all assumptions of varying strength and direction (like vectors). Whether you are working in a risky field or trying to survive on a desert island, ABP has something fresh and useful to say.
Books and papers constantly exhort us to model the problem or domain before proposing a solution in the form of a specification for a new system: but they rarely say much about how to do that. Perhaps that is because the task is actually difficult, demanding models of goals, tasks, and domain structures that are solid enough to stand up to use and reuse. It is all the more remarkable, then, that there already is a book on The Domain Theory, by Alistair Sutcliffe. My first impression of it was that it was ferociously difficult, as it is detailed, analytic, and full of references. On looking at it again, I see that it is like a novel by Charles Dickens: any page of it is clear, direct, and perfectly comprehensible, but the world it describes is large. What it does is nothing less than to define what can happen in a domain – any domain: it’s mind-boggling. The book will be perfect on the desert island, as I’ll be able to go through it, a page or two at a time, reflecting on the clarity of each model, and its possible uses in a world far away.
I must clearly have a book which is unequivocally about software engineering, but is also both fresh and durable. My choice in this category is Beyer and Holtzblatt’s rich, practical and insightful Contextual Design. This is a many-faceted book: the writer of the foreword describes it as being about human-computer interaction, which is where the authors came from, but it’s far more than that. It covers requirements, design, modelling, understanding of work, defining the culture and viewpoints of ‘customers’ (in fact, of many different stakeholders), validation, and life-cycle selection. It shows how each modelling activity feeds into the next, and how cross-checking works. The work proceeds as an inquiry cycle, like John Heron’s Co-operative Inquiry (an Action Research method) and indeed Colin Potts’ independently-devised SCENiC method for requirements.
In Heron's scheme of things, and on the evidence of this book Beyer & Holtzblatt’s, practical knowing is the highest form of knowledge, above “propositional” or head knowledge. There is no place for any of us to look down on “non-technical” people: they are the experts in what they do. This doesn’t mean a reverse-snobbery contempt for academic knowledge, either. Beyer & Holtzblatt, like Heron, are perfectly familiar with the literature in their field, but they wear this learning lightly: they treat it as of value only in so far as it helps people to create better, more “customer-centered” systems. It’s not an accident that Polanyi’s Tacit Dimension is among their references: skill, the practical form of tacit knowledge, is central to their approach. Skill is acquired by apprenticeship, and this is true of requirements people just as much as it ever was of craftsmen:
“We find that people with no special
background in ethnography learn how to conduct effective interviews much
more quickly by acting like an apprentice than by memorizing a list of
effective interviewing techniques. Building on this relationship model
creates a strong basis for learning about work.
Craftsmen, like customers, are not natural teachers, and teaching is
not their primary job. But they do not need to be: the master craftsman
teaches while doing. ... As he works, the structure implicit in the work
becomes apparent because both master and apprentice are paying attention to
it.”
So much experience has gone into Contextual Design that it repays re-reading with further insights. Somehow, in the face of all the complexity, it manages to be at once detailed and simple, informative and infectious: perhaps that is the hallmark of a desert island book.
Beyer, Hugh and Holtzblatt, Karen. Contextual Design: Defining Customer-Centered Systems. 1998. Morgan Kaufmann.
Checkland, Peter and Scholes, Jim. Soft Systems Methodology in Action. 1999. Wiley.
Dewar, James. Assumption-Based Planning: a Tool for Reducing Avoidable Surprises. 2002. Cambridge.
Schmincke, Hans-Ulrich. Volcanism. 2004. Springer.
Sutcliffe, Alistair. The Domain Theory: Patterns for Knowledge and Software Reuse. 2002. Lawrence Erlbaum Associates.
(c) Ian Alexander 2007, 2008