Title: The Wall

Dear Francis,

My copy of the July edition of C Vu arrived on 19th August, nearly a week after the closing date for the competition.

Reading the editorial about type A & B brains, I think that you have succeeded in answering your own questions about lack of contributions to ACCU's publications - the majority of people who belong to ACCU do so because they are programmers and these people generally have poor language skills. I don't say that you should not encourage people to develop those skills, but expecting a deluge of articles or letters might seem rather optimistic.

It also ties in with Pete Goodliffe's article on writing specifications. I much prefer to work with a written specification than with the usual vague verbal one, and if the client doesn't write it, then I try to write something myself before I start coding. However, there is one reason that specifications are not written that he omits:

3) Managers do not want them.

Writing words is seen as unproductive, writing code is what we are paid for, and what we are good at. Take, for example, the pretend requirement cited:

"The user interface shall consist of a black rectangle containing the words 'Don't Panic' in a red san-serif typeface at 13pt." I worry that the preciseness of "13pt" is mixed with the vagueness of "a black rectangle". How big? Where on the screen? (indeed, is it on a screen?) Etc. Now if it had read:

"The user interface shall consist of the words 'Don't Panic' displayed in large, friendly letters"

I would be much happier with the consistency, but not the preciseness.

To get the original specification to be sufficiently precise that two programmers would produce exactly the same image on the screen would take so many words, and require the writer to experiment with size, position, colouring, that it would be quicker to implement it than write down the conclusions and implement it later.

I think this is why many people get into the habit of not writing specifications, or managers not wanting them, because in order to create the precision which removes ambiguity takes far more words than code to implement it. This is true of small tasks, the sort that we all start on as trainees, and it is not obvious at what level of complexity a detailed specification becomes a benefit rather than a hindrance. By the time that it is obvious, the code-test-and-maybe-document working pattern has long been established. Anyway, aren't we all encouraged to write self-documenting code?

And yet there are a fair number of competent writers, and a disproportionate number of ACCU members seem to be in that group. It is possible to learn, but to do so one has to start by doing some writing and getting others to look at it. My wife would assure you that I definitely do not multi-task. Only recently I managed to boil two eggs dry with the result they exploded.