< Prev Next >
NATO SOFTWARE ENGINEERING CONFERENCE 1968
39
5. Production
software projects has been withdrawn. This is indeed a frightening picture.«

As was pointed out by d’Agapeyeff, Europe is not lagging far behind:
d’Agapeyeff: (from Reducing the cost of software)
»In 1958 a European general purpose computer manufacturer often had less than 50 software programmers, now they probably number 1,000-2,000 people; what will be needed in 1978?«
The question arose as to whether it was necessary to have large teams on a single project.
Buxton: The good systems that are presently working were written by small groups. More than twenty programmers working on a project is usually disastrous.
Perlis: We kid ourselves if we believe that software systems can only be designed and built by a small number of people. If we adopt that view this subject will remain precisely as it is today, and will ultimately die. We must learn how to build software systems with hundreds, possibly thousands of people. It is not going to be easy, but it is quite clear that when one deals with a system beyond a certain level of complexity, e.g. IBM’s TSS/360, regardless of whether well designed or poorly designed, its size grows, and the sequence of changes that one wishes to make on it can be implemented in any reasonable way only by a large body of people, each of whom does a mole’s job.
The term ‘the problems of scale’ was used to describe the problems of large software systems.
David: (from Some thoughts about the production of large software systems (2))
»Regardless of how brave or cowardly the system planners happen to be, they do face difficulties in undertaking large software projects. These have been called ‘problems of scale’, and the uninitiated sometimes assume that the word ‘scale’ refers entirely to the size of code; for example, any project of more than 50,000 source statements. This dimension is indeed a contributory factor to the magnitude of the problems, but there are others. One of increasing importance is the number of different, non-identical situations which the software must fit. Such demands  complicate the tasks of software design and implementation, since an individually programmed system for each case is impractical.
A related dimension involves the number of different hardware configurations which the software must accommodate, and another is the range of input error conditions which it must handle gracefully. I’m sure you can think of many more. So, the problems of scale grow with many factors in addition to sheer code size. «
Opler: A logarithmic scale in units of man-years is a useful means of characterizing the scale of a software project. People discussing techniques and possible solutions to the various problems associated with the production of software systems should make clear what scale of system they are considering — 1, 10, 100, 1000 ... man-years.
The reasons that scale brought problems in its train were discussed by David and Harr.
David: (from Some thoughts about the production of large software systems (2))
»The problems of scale would not be so frightening if we could at least place limits beforehand on the effort and cost required to complete a software task. Experience indicates, however, that in the past (and probably in the foreseeable future) estimates of the effort (man-years) to complete tasks involving new software concepts are likely to be low by factors of 2.5 to 4. Similar factors, perhaps not as great) are common for code size and performance. When one considers that a change of 20-50% in any one of these items can mean the difference between economic and deficit operation, one can indeed sympathize with the person who must commit his company or himself to such a task.
Many factors contribute to this situation. There is no theory which enables us to calculate limits on the size, performance, or complexity of software. There is, in many instances, no way even to specify in a logically tight way what the software product is supposed to do or how it is supposed to do it. We can wish that we had the equivalent of Shannon’s information theorems, which tell how much information can be transmitted over a channel of given bandwidth and given signal-to-noise ratio, or Winograd’s theorem specifying the minimum addition