The Programmer as Designer…

VECTOR Vol.3 No.4

The Programmer as Designer, The Designer as Detective

by Robert Pullman

Rule of Thumb 1:

The more time one puts in design, the less time one puts in programming.

The assumption being that the design work progresses towards simplifying the problems that the system poses.

The essential problem that a system poses is how to satisfy all the constraints of the system simultaneously.

The first step, then, is to consider the constraints. the smallest project, though, both the programmer and the client ought to share each.

Rule of thumb 5:

The responsibility should begin with the programmer being in on the specification.

J think we’re in 1987 now, a safe distance from the notion that programmers are oddball introverts, more comfortable with machinery than with people. We have all the natural urges and characteristics of the most moyen John and Jane. There is simply no reason why the programmer should not be there from the very beginning  taking notes, asking and answering questions, making suggestions.

The less experienced the programmer, the more important it is, at least to the programmer’s long-term development, to be involved full-cycle in the project. Sure, it might be an array of confusion at first, but with time come poise and polish.

One of the worst predicaments to be in is to have responsibility without authority: authority as in author, as in author of the spec.

Conversely, if the programmer participates in formulating (formula: little beauty) the spec, and the brainstorming that precedes and surrounds it, the programmer can identify with the project. Rule of thumb 6:

There is always a tolerance range in a computer system. The client lives with” certain shortcomings, enjoys certain surplus features. It never hurts to deliver more than was required. Sometimes a pittance of extra time on something seemingly uncalled for makes all the difference.

I’ve yet to write a system that implemented squeaky cleanly. I don’t think that perfection in a system is any more feasible than the perfect automobile or cheesecake.

100

VECTOR Vol.3 No.4

There are, however, essentials in the importance of the system. From a pure point of view they are mechanical in nature, something to be put in code and executed by a machine. From practical point of view, the essentials reside in what the client could tell you, in what you know from experience to be required. The key, as best as I can summarize, is not in some sort of combinational strategy for optimization. The key is in isolating the truly important requirements in their present sense, and satisfying them in a way that leaves ample room for meeting future requirements.

In short. . - Rule of thumb 7: If you don’t understand the spec, don’t write the program. If you want (or have) to write the program, rewrite the spec so that you understand it. And, nearly a corollary: Rule of thumb 8: If you understand the spec, you have already solved the crucial design problems. The hardest design problems might be ahead of you, but you are on the right track.

APL SOFTWARE

A selection of currently available software:

* INTERPROCESS SYSTEM SOFTWARE  includes many significant enhancements to both VSAPL and APL2 including AP124 for APL2 and the very efficient AFM  shared file sub-system. * PANEL Full Screen Manager * PFS Program File System * RDS Relational Database System * POWERTOOLS/PG

Full training and support available with all our software.

For a more comprehensive list or details contact Philip Goacher on 03727 21282 at 27 Downs Way, Epsom, Surrey KT18 5LU.