Sir Alan Muir Wood
There is an odd strand in systems thinking which persistently holds that opposite ends are the same – that things come full circle, that start and finish meet.
Or to put it in systems jargon, the specifications are the first version of the system; if you can find a way to execute the specifications – with paper prototypes, or simulators, or rule engines or whatever, then you are already exploring the real behaviour of the system.
A tester like Dorothy Graham can say that the time to begin testing is with the requirements: the end starts at the beginning.
Christopher Alexander claimed that problem and solution process must match:
“there is a deep and important underlying structural correspondence between the pattern of a problem and the process of designing a physical form which answers that problem.”
The patterns community in software engineering devoutly wishes to believe so: not only that form follow function (deer have long legs to run fast, lions have claws to kill); but far more controversially, that process follows problem.
Opposite ends are certainly linked: at least by the journey between them, and often much more strongly.
This point is made in various ways in our culture, not least through humour: many a true word is spoken in jest.
Oscar Wilde joked that foxhunting was the unspeakable in pursuit of the uneatable. At least the latter adjective is undeniable; but much of the force of the joke lies in Wilde’s equation of the animals at opposite ends of the pursuit, through their grammatical similarity of construction, and their rhythm and rhyme. Wilde’s equation of the two ends is even clearer in his unkind characterisation of fishing: a piece of string with a fool at either end.
Sir Alan Muir Wood
The great engineer Alan Muir Wood quipped that a tunnel is a hole with a geologist at one end, and a lawyer at the other. As the mediator in the embittered Channel Tunnel project, he had plenty of experience of both ends of that sort of tunnel.
Failed projects, too, are holes, but of a different sort. A yacht, a weary millionaire remarked, is a hole in the water into which money may be poured. There is no semblance of a far end here.
But don’t all projects start from the clear light of day with a customer, or a product manager with a bright vision, dive into a dark place, and emerge only much later into a different sort of daylight with a newly-born system or product? From the smiling wedding and the joyful conception to the painful but blessed moment of birth, the baby system grows in the dark – from zygote to strange blastula and gastrula to miniature embryo and then as an increasingly recognisable foetus. And often, indeed, there is still to come a lengthy and sometimes difficult childhood and adolescence before the young system matures into something close to the desired bringer of efficiency and useful service.
The software or systems engineering life-cycle, indeed. In the textbooks, this is portrayed as an onwards-and-upwards movement, a steady, logical, even inevitable (hah!) progression towards the desired goal. Ensuring project success! – that sort of thing. Wiser engineers speak of evolution and prototyping and assessment and evaluation, acknowledging that there will be many twists and turns along the way. Far from being wasted effort, these explorations are exactly how knowledge is acquired, enabling the best solution approach to be chosen.
Muir Wood was remarkable among tunnelling engineers in pioneering "observational design" in his field. You didn’t just choose a tunnelling method and blindly follow it; but like a mole with its blind eyes but sensitive vibrissae, you delicately monitored the effect of your tunnelling as you went along, and modified what you did accordingly. Muir Wood was heavily criticised for his daring Cargo Tunnel in Heathrow Airport (I say “in” advisedly). The Cargo Tunnel went right underneath the runway, at only a few metres depth beneath the concrete, while the runway remained in continuous service. How did Muir Wood know that this would work? You have to be fairly sure of yourself as a young man to take that sort of risk. The result was a tunnel that was far more convenient in operation than a deeper tunnel would have been – there are no long steep ramps down and up.
If the ends do meet, if goal and result are to be the same – as is much to be desired – then Muir Wood is right: development must be “observational” – cyclic, co-operative, contextual, reflective, iterative, evolutionary, rapid prototyping, agile, even extreme. What a lot of times we have reinvented this particular wheel!
For wheel it must be. The only way anyone knows to make a complex system is to make a simple system first, and to improve it, again and again.
Government in particular constantly attempts to create enormous systems of undreamed-of complexity to manage “all” patient records, or “all” tax affairs, or “all” military procurements, or “all” citizen identities, or … the melancholy list goes on and on. These systems-to-be do all have something in common: they promise a rosy new dawn; they are far larger than their predecessor systems; oh, and they don’t work. Money is poured lovingly into them, as a billionaire pours cash into a luxury yacht which languishes forever in harbour. And every year, the Public Accounts Committee and the Audit Commission patiently uncover the murky truths of these wretched projects:
It’s no way to make ends meet.
Ian Alexander
Books you may like:
