But thankfully found again. Through a series of circumstances too complicated to relate, I’ve recovered (after its perambulations of six years or so) my copy of Michael (A) Jackson’s Software Requirements and Specifications: a lexicon of practice, principles and prejudices. (SRP in what follows)

I’d first encountered Jackson through training courses in the 80s on software design — and have to admit that at that point I regarded the rather specific techniques of Jackson Structured Programming and Jackson Structured Design as somewhat old-fashioned: they seemed to be catering for a class of systems that formed a diminishing part of the software ecology, even then. (And I have to add, I was then and am now no fan of people naming methods after themselves or their companies).

But SRP is one of my all-time classics. The title of the book is something of a misnomer: while the ethos of the book is very much around understanding the relationships of the software we build to the circumstances in the world which it is designed to address, it’s structure (a series of over seventy short essays on subjects ranging from ‘Ambiguity’ to the ‘Workpieces Frame’) lets Jackson roam freely over the domain of software development, sometimes specific, sometimes general, sometimes philosophical. The principle of dispassionate methodology (in the section on Method) is particularly apt in the current world of Lean and Agile:

Don’t get your method advice from a method enthusiast. The best advice comes from people who care more about your problem than their solution.

There are clear descriptions of some specific problems (a sweet two pages on the Bridges of Konigsberg, for example, and a description of a — physical — package routing system that kept us busy for a while at Object Designers in the Syntropy days), and more reflective pieces on the nature of description and classification.

SRP introduced the concept of Problem Frames, which Jackson later expanded in a book of the same name. A Problem Frame is a high-level description of the kind of system that’s under consideration, and the way its constituent parts are related to a set of intentions in the world. It has a lot in common with the XP notion of system metaphor: a set of concepts and terms that help us make sense of the system we’re building, and relate the things we’re building to each other and to the system as a whole. Problems arise when we misunderstand the world, and attempt to build a system using a frame which doesn’t fit the solution.

The way in which we tackle development now is, of course, very different from the way it was done in the 80s and 90s. We know now that planning — for example — is a continuous activity, not just a process that produces an artefact. I think we benefit from regarding requirements and specification in the same way: not as documents, but as ongoing processes. If we do this, it’s clear that the need to think clearly about meaning, description, classification, scope and span hasn’t disappeared, but it seems to me that in the agile world we don’t do this as much as we should. Looking at this book again, I’m reminded of the wisdom we’re in danger of losing: who now would take a second look at a book with the words ’specification’ and ‘requirement’ in its title?

I’ll leave you with a favourite extract of mine, a story about software development from the section on Brilliance. Following an in-house course, the DP manager asks Jackson into his office:

“What do you think of Fred?” he asked. “We all think Fred’s brilliant.” “He’s certainly very clever,” I said. “He’s not very enthusiastic about methods, but he knows a lot about programming.” “Yes,’ said the DP Manager. He swivelled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. “Fred did that. It’s the build-up of gross pay for our weekly payroll. No-one else except Fred understands it.” His voice dropped to a reverent hush. “Fred tells me he’s not sure he understands it himself.”

“Terrific,” I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flow chart. That matched my impression of Fred very well. “But what about Jane?” I said. “I thought Jane was very good. She picked up the program design ideas very fast.”

“Yes,” said the DP Manager. “Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn’t really proved herself yet. We’ve given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren’t really difficult at all. Most of them turned out to be pretty simple. She hasn’t really proved herself yet — if you see what I mean?”

I saw what he meant.