< PrevNext >

50
NATO SOFTWARE ENGINEERING CONFERENCE 1968

5. Production
»Also, system programmers vary widely in their productivity. Figures from an experiment by SDC indicates the following range of performance by 12 programmers with 2 to 11 years’ experience in completing the solution to a specific logic problem (Comm. ACM 11 (1968), 6):
Performance on Worst/Best
Debug Time Used 26/1
Computer Time Used 11/1
Coding Time 25/1
Code Size 5/1
Running Time 13/1
These figures confirm my own informal observations. Of course the importance of individual talent to projects generally is widely appreciated and is traditionally reflected in promotions and dismissals. Yet, in software projects, talent is often so scarce that marginal people are welcomed. More to the point, the range of productivity indicated above seems quite large compared to what one might expect or tolerate on a hardware project, increasing the difficulty of accurate estimation.«
Fraser: I would never dare to quote on a project unless I knew the people who were to be involved.

Opler: In managing software projects the real problem is ‘spot the lemon and spot the lemon early’.
This started a somewhat surprising line of conversation.
David: I have heard rumours that the Japanese are extremely good at producing software.
Perlis: There is apparently some truth in it. I believe it to be due to three factors.
1. A man stays at one job for his entire working life — there is no concept of mobility.
2. They have a tremendous amount of self-discipline.
3. The complexities of their language give them good preparation for the complexities of software systems.
Opler: I agree — yet by American standards they work long hours for low pay.
There were several comments on the personnel factors involved in very large projects:
David: (from Some thoughts about production of large computer systems)
»Among the many possible strategies for producing large software systems, only one has been widely used. It might be labeled ‘the human wave’ approach, for typically hundreds of people become involved over a several year period. This technique is less than satisfactory. It is expensive, slow, inefficient, and the product is often larger in size and slower in execution than need be. The experience with this technique has led some people to opine that any software system that cannot be completed by some four or five people within a year can never be completed; that is, reach a satisfactory steady-state.«
d’Agapeyeff: There is the problem of morale. For example I have no idea how you keep your people when you try the ‘human wave’ approach to the production of large systems. In my experience programmers are rather difficult to shove around like platoons in the army.
The benefits of the small team, in those situations which it is sufficient for, were discussed by Babcock and by Cress and Graham.

Babcock: (from Variations on software available to the user)
»Before I leave the software area, let me discuss briefly the staff. We selected a few very highly talented, creative people who 1. designed the system, 2. implemented the system, 3. continually developed and researched new capabilities for the system.