The staff comprised over a century of programming experience and I feel this tight control over the entire production is one of the major factors in the success of Rush. No minor programmer ever wrote a bug fix, no minor programmer ever maintained the system. From the beginning, it has been a group of experts who followed every development to the finish.«
Cress and Graham: (from Production of software in a university environment)
»Much of the design and programming is done by students. They are eager to learn, full of energy and add a vitality to the project which keeps it alive. But they must be supervised!
We have never experienced personnel turn-over during the development of software. This is probably because of the desire to be successful, coupled with the relatively short duration of the projects. We try not to hire people who want a job; instead we try to hire people who want to do the job under consideration.
A common property of all our project groups has been that they have been small, and faced with a relatively well-defined task. We find that, with the objective always in sight, the spirit of the group can be maintained.«
Finally, we include comments by Perlis on how the realities of personnel factors might be faced in structuring a large group of people:
Perlis: A man can communicate with about five colleagues on a software project without too much difficulty. Likewise he can supervise about five people and know pretty well what they are doing. One would structure 120 people in three levels, in which no man is talking to more than about eight people, both across his level and up and down — which is well within our capabilities I think, since most of the communication will go across rather than down. We have confused the simplicities of administration with the aims of production. When someone comes into a structure we naturally assume that he starts at the bottom and works his way up, whereas the bottom is the place where the information is most difficult to get at in order to find out what you should be doing. So a new person should start perhaps one level down from the top. Another interesting concept we might apply is that used in the Air Force, to fly a number of hours each month, in order to retain one’s ‘wings’. So, in a system which will take a long time to complete, for example a year, nobody should be allowed to function permanently at one level, but should percolate. In a situation where code actually has to be produced, nobody should be allowed in the system who doesn’t write some given number of lines of code per month. I think that one of the major problems with the very large programming projects has been the lack of competence in programming which one observes as soon as one goes above the very bottom level. People begin to talk in vague general terms using words like ‘module’, and very rarely ever get down to the detail of what a module actually is. They use phrases like ‘communicate across modules by going up and then down’ — all of the vague administratese which in a sense must cover up a native and total incompetence.
5.2.3. PRODUCTION CONTROL
One of the big problems of controlling the production of a large system is obtaining information which will reveal how much progress has been made.
Fraser: (from The nature of progress in software production)
»One of the problems that is central to the software production process is to identify the nature of progress and to find some way of measuring it. Only one thing seems to be clear just now. It is that program construction is not always a simple progression in which each act of assembly represents a distinct forward step and that the final product can be described simply as the sum of many sub-assemblies.
…
Various attempts were made at measuring progress without much success. As the work advanced we evolved a simple method of accounting for the components that went to form or support the final product. But this approach was no better than the various ‘seat of the pants’ methods which are still much in evidence. We experienced one of the classic problems of metering: that of interference between the measuring device and the process that is being measured. At one time we kept totals of the number of subroutines that were classed as ‘tested’ and compared this number with the total number of subroutines in the final product. But, once a programmer’s performance is formalised in this way it changes his attitude to his work. The effect was to pro