A few decades in computing

Electronic computers came on the scene during the war against Hitler, while my parents were children. My father wrote a book on analogue computers at just about the point when digital computers displaced them. Throughout his career, they have played a pivotal rôle in his work-place. Among other things, that's why, as an 18-year-old seeking a job, I was living within two miles of a place which actually had some use for a bright young lad who could program computers and wanted to earn some money between leaving school and becoming a student.

In this page, I endeavour to relate my first-hand experience of the world of computers; which is heavilly coloured by my career history, mostly working for businesses whose only (or principal) product is computer programs. Many folk who work with computers do not work for such businesses – they support the process of a business producing some other product, by deploying computers and software to provide the infrastructure that facilitates the primary business and by helping their colleagues to understand and make use of that infrastructure. I have a little experience of that, also; if nothing else, well-run software houses employ folk in such rôles, quite separate from the folk who produce the primary product; and many of these have proven good friends. A hint to all: they appreciate being appreciated, and prefer it if you at least try to make sense of your problem before either trying to fix it yourself or calling them in.


As soon as we started programming, we found – to our surprise – that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.

Maurice Wilkes, designer of EDSAC, on programming, 1949

Wilkes was lucky. I have spent a large part of my life finding and fixing mistakes in other people's programs.

This page is also a presentation: if you can persuade your user agent (a.k.a. web browser) to render it for media type projection (e.g., in Opera, by entering full-screen mode with F11) you won't see this introduction, you'll just see some slides. Because this just deploys some standard web technoligies, one document can serve as both the presentation – essentially comprising cues to remind me of what the salient points are in each section – and the full text.

Pupil (1976ish–1981)

The ancient main-frame:
Research Machines Ltd.:

Computational Fluid Dynamics (1982, 1983)

The next village round Leicester from home – Whetstone:
Modelling the flow of boiling water under very high pressure that's been released:
The tortuous pump simulation and the bug:

Student (1980ish–1986)

School and University – primitive desk-top publishing:
Summer job 1985 – Finite Element Modelling:
University – Big Iron from Big Blue:

Parametric Solid Modelling (1988–1991)

Image Segmentation (1991–1993)

Synthetic Aperture Radar (SAR) and coherent speckle:
Work does not happen in a vacuum:

Interlude: Moore's law

Home PC
Memory: emacs @ work

Informatics (1993–1995)

The problem – coercing data between world-views:
Making the most of networks:

Web-mastery (1995–1996)

Geographical Information Systems (1996–2000, part I)

GIS and other uses for lasers:
Technical sophistication.
When colleagues aren't angels:

ISO 9001 done properly (1996–2000, part II)

Know Thy Self – that thou mays't improve.
The Law was made for man, and not man for the law.
continued …

Tool-wright (1996–2000, part III)

Kevan's legacy:
Making tools support the process.
Incompatibilities and Surprises

The Web Itself

Zeus (2000–2001):
Opera (2002–…):


Experienced software engineers know that perhaps 30% of the cost of a software product goes into specifying it, 10% into coding, and the remaining 60% on maintenance.

Ross Anderson.

Valid CSSValid HTML 4.01 Written by Eddy.