(Desert Island Column. Automated Software Engineering 6(3): 315-320, 1999
by Tim Menzies)
Editors note: the following exchange is totally imaginary and any
connection to editors or authors, real or otherwise, is totally
coincedental.
|
Before |
From: tim@menzies.com (Tim Menzies- TM)
To: ban@doc.ic.ac.uk (Bashar Nuseibeh- BN
Subject: Status of my submission to your journal.
Date: Jan 29, 199X
Writing to enquire about the status of my article "Fundamental Flaws
In Nuseibeh's Requirements Inconsistency Management Tools" to the
Journal of Automated Software Engineering.
|
|
Day 1 |
From: BN
To: TM
Subject: Journal submission
Date: Jan 30, 199X
Your paper is very thought provoking and is being reviewed. Why don't we
meet to talk about it? The outer islands of the Whitsunday Passage are
nice this time of year. Oh, I might be a little delayed getting
there. Better take something to read.
|
|
Day 3 |
From: TM
To: BN
Subject: Awaiting your arrival
Date: Feb 2, 199X
Have arrived outer Whitsundays with several books to read. I am more
of an artificial intelligencer than a software engineer and my choice
of reading reflects that bias. For example, I am currently reading a
special issue of the Artificial Intelligence Journal (AIJ), 59, 1993
(Bobr94). In terms of reading the least and learning the most, I know
of no other collection in AI that comes even close to this one.
The issue was by compiled by Daniel Bobrow to mark the 50th edition of
AIJ. Bobrow contacted the authors of the papers cited most in the five
years after their publication in AIJ between 1970 and 1991. He asked
them to write a short retrospective essay on their work commenting on:
- The key contributions of their work, as well as what was most
misunderstood in or about the paper.
- What were the key issues then and now?
- What would they do differently now, given the benefit of hindsight?
- What (small number of) papers reflect the future of the work
described in that paper?
The papers are divided into six sections:
- Foundations: retrospectives on circumscription, autoepistemic logic,
the knowledge level, probabilistic logic, Dempster-Shafer reasoning,
belief networks, Mackworth's constraint satisfaction technique, and
the ATMS.
- Vision
- Qualitative reasoning (QR)
- Diagnosis
- Architectures; e.g., frames, blackboards
- Systems; e.g., STRIPS, DENDRAL, and XCON.
I found Kuiper's articles in the QR section especially
interesting. Years later, Kuipers recognises that his famous QSIM
system was really an convoluted implementation of Mackworth's node,
arc, and path consistency algorithms. This is a fascinating statement
since other famous QR algorithms (i.e. Forbus's QPT system) can be
reduced to QSIM and hence to Mackworth's algorithm. My own conclusion
from the QR retrospective is that the 1980s American QR research,
while exciting and innovative, confused rather than clarified a class
of reasoning tasks.
Each paper is very short and the collection as a whole gives an
excellent overview of large sections of the state-of-the-art in AI, while
avoiding excessive technical detail. The special issue does miss
some material, however. For example, it makes no mention
of machine learning, or non-symbolic techniques (e.g., neural networks
or genetic algorithms). Still, it is an impressive set of papers.
Please reply with details of your travel plans. A word of warning:
transport here is very limited and the hurricane season is approaching
(the locals call them "cyclones"). If you do not arrive soon, we may be cut
off for some time.
|
|
Day 16 |
From: BN
To: TM
Subject: Arrival delayed
Date: Feb 15, 199X
I'm sure the locals are exaggerating regarding the weather. Please
enjoy your time there while we review your most interesting
paper. Just don't swim in the water: those jellyfish stings can kill!
Oh, and watch out for the mosquitoes- malaria is such an awkward
illness. Sorry to say, I am held up with conference commitments but
plan to join you as soon as possible. Say, what else are you reading?
|
|
Day 17 |
From: TM
To: BN
Subject: Still waiting for your arrival
Date: Feb 16, 199X
Good to here the reviews of my article are proceeding. Things on this
island are pretty grim, what with the hurricanes and all. Still,
reading gets me through. I've been wondering what three books I'd give
a novice software engineer and I've decided that they should be:
- Sedgewick's book on Algorithms (Sedg92). Software engineers often sneer at
algorithmic analysis of software since, in the usual case, analysis
methods for a 4 line program are just not relevant when designing
software in the large. Nevertheless, I think all software engineers
should read Sedgewick. Pragmatic demands often require us to design
in a somewhat "quick and dirty" manner. We often forget that
software can be clean and the Sedgewick text is a gentle reminder
that software can be very clean indeed. Just as actors practice
being wind and fire before they play Shakespeare, software
engineers should practice the purity of algorithm design before
ascending to large systems. Also, sometimes the very thing you need
to optimise some process is available for you right here in Sedgewick
(Sedgewick's section on string searching springs to mind). Earlier
versions of this book
expressed its algorithms in Pascal or "C". This version uses "C++"
(though what is gained from coding algorithms in "C++" is not
clear to me).
I find this text on algorithms much more approachable than
other, more theoretically daunting algorithms texts.
- Date's database text (Date96) is an excellent companion to the
Sedgewick text. While Sedgewick was concerned with programming in
the small, Date is concerned with the design of systems to manage
resources so big, they must be stored on disc. The contains the
full spectrum of technical details needed to build and use
databases- right the way from page sets and file blocks (appendix
A) to high-level object-oriented databases. Along the way we learn
about query languages, transaction processing, and the like. After
conventional databases have been dealt with, Date goes on to
research frontiers in databases. For a researcher, one of the
strongest features of the book is that each chapter contains an
extensive annotated bibliography. Using these bibliographies, a
researcher can quickly bootstrap themselves into the database field.
- Donald Norman's "The Design of Everyday Things" (Norm90). Date's book may
leave the reader with the impression that much of the software
problem has been solved. Norman's text is a great antidote to such
optimism. This book concerns itself with the general problem of
design (and software design is just one special kind of design).
It contains many wonderful examples of bad designs and offers some
sobering insights. While many of the low-level issues of algorithm
design and data storage have been addressed (see Sedgewick and
Date), the general problem of producing systems that people want is
an open issue. For example, bad designs usually result in
cancelled projects. However, it can take many iterations to arrive
at a good design. Norman's preferred solution is user-centered
design processes in which the development group and the user group
work hand-in-hand to evolve their systems. Note that such evolution
is the antithesis of structure waterfall development- an issue
software managers should ponder deeply.
Sorry to here that your arrival time here has been delayed, but its just as
well. The hurricane came and took away the air strip, my tent, and the
short-wave radio tower (I'm sending this letter via a corked bottle-
hope it gets through). Sunburn, and dehydration are my main problems
right now. You might want to think of waiting till the local
emergency services repair the sanitation again.
|
|
Day 29 |
From: BN
To: TM
Subject: Hurricanes are not such bad things
Date: Feb 28, 199X
Great to hear you are not letting a little tropical wind ruin your
trip. Yes, I'll take your advice and delay my arrival. In fact, I am
leaving now for a six-month sabbatical. About your paper: the
reviewers are having some problems with your catalogue of my greatest
mistakes. I'll have to help them out, just as soon as I get back from
my sabbatical. Talk to you then! Oh, and I'm air-dropping this note
with a voice recorder so that even if you can't find a post box (they
were all obliterated by your hurricane, right?) you can still do book
reviews.
|
|
Day X |
From: TM
To: ???
Subject: Starving to death
Date: Apr 1, 199X
Still stuck on this god-forsaken desert island. Ate the last of the
missionaries today. The isolation and the heat had sent them mad
anyway. Don't know what I'll do for food from now on but I must say
that my right leg looks very tempting.
I am so sorry now that I wrote "Fundamental Flaws In Nuseibeh's
Requirements Inconsistency Management Tools". Clearly, I was totally
wrong and am being punished for my academic sloppiness. I still dream
that one day, Dr. Nuseibeh will come to save me. Until
then, I must be faithful to his directives and review books.
I last mentioned three introductory software texts. To balance that, I
want to mention two collections of reading that I regard as being on
the research frontier:
- Expertise in Context, edited by Feltovich, Ford, and Hoffman
(FFH97). This collection strikes to the heart of a core issue in
design: can we write down a specification correctly? The lesson of
this collection must be "no". Any record of business knowledge is a
representation of human knowledge and that kind of knowledge is a
dynamic and evolving thing. This collection contains much that is
worth a several reads but my favorite article in this collection
is the Shalin et.al. contribution (chapter 9). In two pages they
summarise the debate between the objectivists and the
contextualists. They then go on to design and conduct an experiment
on the central issue dividing the fueding camps: do experts reuse
some concept of "accepted practice"? If yes, the objective
knowledge exists and can be reused. If no, then reuse is
unlikely. Their answer is a middle ground between the two
camps. Yes: experts do modify their behaviour according to a
consensus of correct expert behaviour. However, it is only the
novice who slavishly applies accepted practice. Real experts,
argues this article, use a library of accepted practice as a place
to initialise a possible solution. The demands of the particular
problem-at-hand then may require extensive modifications to the
extracted solution. Further, when the expert applies the modified
solution, they also insert some monitor to check if their adapted
solution is successful. If not, the expert will then modify the
library of accepted practice. That is, when experts used "accepted
practice", they often modify it.
- Design Rationale, Morran and Carroll. The most common question
maintenance crews ask is "why did they build it this way, and not
that way?". The answer to this question is a design rationale: some
record of the reasons why software was changed. Rationales are
expensive to create and much of this book concerns itself with
methods for simplifying the creation of such rationales. Design
rationales should be studied for their own sake. However, this book
can also be used for another purpose. In order to build a design
rationale, a researcher must first commit to some definition of
design. A study of design rationale is hence a study of current
design practice. A fascinating insight offered on page 3 of this
collection is that there are at least four different paradigms of
design in use today:
- Reuse: build today's house out of lego blocks created when
building yesterday's house.
- Search: build the house by exploring the space of all possible
lego blocks.
- Argue: build the house by getting a community of stakeholders to
argue about what makes for a good lego block.
- Fix: build the house by creating some part of it, then let that
part offer feedback to the designer on limitations of that part.
Interestingly, the paradigm used by the majority of designers
(Reuse) is the least explored by the design rationale community
(though see the Fischer et.al. discussion in chapter 9 on reuse of
old rationales). Perhaps the reason is that reuse is a second-order
problem. Before we can reuse lego blocks, we have to know how to use them.
Design paradigms "argue" and "fix" are all about using lego blocks in a
situation: design-as-fix explores if the lego block works for the current
problem; design-as-argue explores if the lego block is acceptable to
the community of users? The state-of-the-art in the design
rationale community is to explore the problem of using
software. Once that is solved, then perhaps we can move on to
reuse.
Speaking of reuse, I've found another way to pass my time. I've been
rewriting "Fundamental Flaws In Nuseibeh's Requirements Inconsistency
Management Tools". Its now called "Nuseibeh's Penetrating Insights
into Inconsistency Management". The rewrite is coming along fine. But
wait, what's this coming towards me? A helicopter! I'm saved! Saved!
|
|
The End |
From: BN
To: TM
Subject: Notification of acceptance of paper
Date: Apr 1, 199X.
Have you in sight. Please have the rewrite completed before we pick
you up. Looking forward to publishing your revised article. Hope you
enjoyed your little holiday on a desert island.
|
|
References |
- Bobr94: D.G. Bobrow (ed) "Artificial Intelligence in Perspective"MIT
Press; 1994, ISBN: 0262521865.
- Date96: C.J. Date "An Introduction to Database Systems", 6th edition
Addison-Wesley Pub Co; ISBN: 020154329X.
- FFH97: P.J. Feltovich, K.M. Ford, R.R. Hoffman (eds) "Expertise in
Context: Human and Machine", AAAI Press, 1997, ISBN: 0-262-56110-7
- MC96: T.P. Moran, J.M. Carroll (eds) "Design Rationale: Concepts,
Techniques and Use", Lawrence Erlbaum Associates, 1996, ISBN:
0-8058-1567-8 (p)
- Norm90: D. Norman "The Design of Everyday Things";
Currency/Doubleday; 1990, ISBN: 0385267746.
- Sedg92: R. Sedgewick, "Algorithms in C++" Addison-Wesley Pub Co;
1992, ISBN: 0201510596.