Title: The Wall

Dear Sir,

I was most interested in Peter Goodliffe's article Professionalism in Programming Part 3, and I would like to make the following observations regarding specifications and professionalism.

In all but very trivial developments, it is most important that the Project Plan defines the document configuration items to be created, their purpose in the project, their relationship to other project configuration items and their lifecycles. This eliminates the potential for misunderstanding of a document's purpose, which tends to result in a proliferation of 100+ page 'Wuthering Heights'-type documents which no-one can be bothered to read and often get abandoned at about third draft, having wasted a tremendous amount of time.

As regards professionalism, this is related to the first and second 'laws' of systems engineering, which are true for any systems engineering, not just computer-related systems:

The 'First Law of Systems Engineering' is:

All 'good' systems engineering comes from one thing and one thing alone: the solid application of knowledge.

Note that 'good' computer systems engineering does not come from having ISO 9001, a heavy quality management system, the latest CASE tools or automated test tools!

The 'Second Law of Systems Engineering' is:

Any systems engineering can only be as 'good' as the models of the system being engineered.

Optimum specification documents are better constructed in terms of static and dynamic models of the system, as the models fix semantics and facilitate correctness and completeness of the specifications for a particular system's context. This is the area of expertise of professional analysts.

I thought that the definitions given of 'correct', 'complete', 'consistent' and 'verifiable' were too woolly, but they are typical of those found in documentation standards. It is all too easy to be superficial, both in construction of specifications and in their verification. If inadequate specification documents are being created for a project, then this may be because of the 'Universal Law of Incompetence', which is:

In any crap organization, the biggest shit-head is the one at the top.

In my experience of 'poor' projects, typically littered with abandoned documents, this has always held true.

The designated Project Manager must have sufficient knowledge to ensure that optimum processes are in place on the project, and that all participants in the project have the appropriate level of knowledge to carry out their duties within the context of the project and its defined processes.

If the Project Manager has an inadequate level of knowledge for the project, inadequacy is likely to spread throughout the project organization. This can have another effect, in that knowledgeable staff will raise issues that will not be addressed, if even understood! This can result in beneficial knowledge being present in the project, but not being applied, and knowledgeable staff being frustrated. I am sure most of us have been put in this position at some time. Under these circumstances, asking for an improved standard of documentation is pointless, as the project staff know no better.

In my view, professionalism for the individual means the continuing acquisition and refinement of his/her knowledge, by, for example, reading papers and textbooks, attending training courses, learning from more knowledgeable mentors and experimentation.

Unfortunately the sftware industry is one that seems to be woefully short of people who are willing to continue learning. Somewhat ironic.