The analogy with engineering drawings, however, raised the question of measuring the quality of work produced, as well as progress towards the project goal.
McIlroy: I think we should consider patterning our management methods after those used in the preparation of engineering drawings. A drawing in a large organisation is usually signed by the draughtsman, and then after that by a draughting supervisor when he agrees that it looks nice. In programming efforts you generally do not see that second signature — nor even the first, for that matter. Clarity and style seem to count for nothing — the only thing that counts is whether the program works when put in place. It seems to me that it is important that we should impose these types of aesthetic standards.
McClure: I know of very few programming establishments where supervisors actually bother to read the code produced by their staff and make some effort to understand it. I believe that this is absolutely essential.
Buxton: I know of very few programming establishments in which the supervisor is capable of reading code — some present company excepted!
5.2.4. INTERNAL COMMUNICATION
There was considerable discussion on the means by which programmers working on a project might communicate with each other.
Buxton: We could use more and better and faster communication in a software group as a partial substitute for a science of software production. We can’t define the interfaces, we don’t really know what we’re doing, so we must get in a position where we can talk across the interfaces.
Dijkstra: I believe that both the total density of information flow necessary between groups, and the percentage of irrelevant information that a given group gets, can be greatly reduced by effectively structuring the object to be constructed and ensuring that this structure is reflected in the structure of the organisation making the product.
Gillette: An attack on the problem of communication is crucial for successful production. We are not using automation (remote consoles, textediting, etc.) as much as we should.
Buxton: I know myself that if I’m setting up a software group to carry out a project I’m extremely careful that all the people working on it are close personal friends, because then they will talk together frequently, and there will be strong lines of communication in all directions. One in fact uses personal relationships to support technical communication.
Nash: There are dangers in uncontrolled mass-communication. You can get into trouble if people start taking advantage of information that they gain by chatting that they should not know (and which may well lose its validity in a day or so).
A detailed discussion of the importance of careful documentation was given by Naur:
Naur: (from The profiles of software designers and producers)
»In order to characterise the work of the production programmer I would first of all stress the importance of documentation during production. Both the need for documentation of software systems, and the difficulties in filling these needs, are well known items in software work. It is my experience that the most constructive way to solve this problem is to insist that the production of essential parts of the documentation is a natural part of the production of the software program, and that the two proceed in parallel.
In discussing documentation one should keep in mind that this is aimed at the human reader, and should be developed along the principles of report writing set forth in several different texts on the subject. Of particular significance is the insistence, among competent report writers, that reports be structured hierarchically and written from the top of the hierarchy, i.e. starting with a brief synopsis. I feel strongly that in software production this principle should be followed carefully, at all levels of the work. If this is done, the first thing to be done by the software producer about to start writing a piece of software, is the writing of a synopsis of what his piece of program is supposed to be doing. The next level may consist of a description of a few pages describing the essential data structures and the major processes to which they will be subjected. This description should