ments, and I am not sure the experiment was successful. At Control Data we have used text editors, but there is a great bottleneck, and that is getting the original text into an editable form.
Many problems of software engineering were recognized to be of a general managerial nature, as in the following remark.
David: We must distinguish two kinds of competence, or incompetence, one is in the substance of the subject matter, the other comes in when a person is promoted to coordinate activities. There is a principle, a kind of corollary to Parkinson’s Law, called the Peter Principle, named after a high school principal in Long Island. It goes like this: ‘In the real world people are eventually promoted to their final level of incompetence’. That is, if a person is extremely competent at the particular level he happens to be working at, he is immediately promoted. This brings upon him additional responsibility. If he does well at that job he is eventually promoted again, and again, until he reaches the level where he no longer performs satisfactorily, and he is never promoted again. So people are left in a state of incompetence. This, in part, is the problem of any big project area.
Samelson: By far the majority of problems raised here are quite unspecific to software engineering, but are simply management problems. I wonder whether all other branches of large scale engineering have the same problems, or whether our troubles simply indicate that programmers are unfit to direct large efforts. Perhaps programmers should learn management before undertaking large scale jobs.
Randell: I have a question on the huge range of variability of programmer performance. Are similar ranges found in other engineering areas?
David: The variation range in programming is in fact greater than in other fields. Certain remarks reflected on the relation between the group structure and the structure of the systems produced.
Endres: It is important that the structure of the system and the structure of the organization are parallel. This helps very much in communication. Communication should follow the same lines along which decisions are made.
Pinkerton: The reason that small groups have succeeded in the past, and that large groups have failed, is that there is a need for a certain structure of communication, and a structure of decision making in the development of software. This succeeds with small groups, because it can all be done intuitively by one person serving as most of the network, but it has failed with the large groups. For large groups to succeed, (and we do need large groups), we just have to face organizational structure for communications and decisions. Second, this does induce a structure on the system. We ought to consider how a system designed with a group with a certain structure might have a reflecting structure.
Randell: As was pointed out by Conway (How do committees invent? — Datamation, April 1968) the system being produced will tend to have a structure which mirrors the structure of the group that is producing it, whether or not this was intended. One should take advantage of this fact, and then deliberately design the group structure so as to achieve the desired system structure.