Richard's BLOG

Category: IT   Topic: Adding detail to descriptions

The 1980s saw a big rise in the number of methods for developing systems (consultants called them methodologies, so they could charge more for them). Most of these methods incorporated a notion of top-down development, a notion that first appeared in earlier methods for program development.

But many of the system methods did not use top-down as envisaged by the pioneers of program development methods. To understand the difference you have to understand two different kinds of detail.

There's the kind of detail you add when you get nearer to finishing a description at a given level of abstraction. Think, for example, of the detail you add when you write the second half of a method in an object-oriented program. It's detail of the same kind as in the first half of the method. But the method's not complete without it. (You'll see that I am using description in a very general sense.)

By contrast, there's the kind of detail you add when you change to a lower level of abstraction. Think, for example, of the kind of detail to be found in a specification of a method, and the different kind of detail to be found in the code for that method.

The pioneers of program development methods were clear about the difference. In an important paper entitled Program Development by Stepwise Refinement (CACM, Vol 14, No 4, April 1971), Niklaus Wirth says, "In each step, one or several instructions of the given program are decomposed into more detailed instructions."

Developers of system development methods took this to mean that a description of a system could be built by writing a vague, high-level description, then explaining some of the vagueness at a lower level of abstraction, and explaining the vagueness in that description at yet a lower level, and so on. The problem with this approach is that none of the descriptions at any of the levels is, in any useful sense, complete (unless you continue down until you have a working program, but system development methods were meant to produce system specs, not programs).

Now read what Wirth says next in his sentence: "This successive refinement of specifications terminates when all instructions are expressed in terms of an underlying ... programming language." The word specifications is key.

At each level of abstraction we have, not a vague description to be made more precise at a lower level, but a specification appropriate to the current level of abstraction, capable of being implemented (i.e., described) at a lower level.

In a future post, I'll introduce what I call the precision gap that arises if you try to avoid being precise at higher levels of abstraction, and why the gap can make your development process less effective.