had such experience with large projects, or do they have to have their professors go out and as consultants experience large software engineering projects? Then, when they come to exercise the students, do they have to have laboratories of some considerable consequence in software engineering exercises? Otherwise, who is to formulate principles of software engineering that can be used to train software engineers?
Dijkstra: To the question of how one can get experience when working in a university I have two answers: (1) If you undertake something at a university it has to be one of your main concerns to organize your activity in such a way that you get exactly the experience you need. This again must be the main concern in the choice of projects. (2) We have a Dutch proverb: ‘One learns from experience’, suggesting that it happens automatically. Well, this is a lie. Otherwise everyone would be very, very wise. Consequently in a university with limited resources, from the experience one has got one should try, consciously, to learn as much as possible.
David: The problem of how the software engineers will get their practice in precisely the same as in other fields of engineering, and is insoluble. This is recognized in industry, where one makes sure that the young engineers coming in will get the proper kind of experience in time. Really it seems that the problem is less serious in software engineering than in other fields.
Berghuis: We need students better trained in standards, standards of communication, of documentation, of set-up, and of use of software.
Fraser: I was impressed by Douglas Ross’s Session [section 5.3.2] and I am convinced that there is a future in software science or technology. Nevertheless, I am convinced that much of the game in which we are involved is one of making the best of the world around us, understanding what the world wants and matching what science can offer. This, to my mind, is truly engineering. What worries me about the courses I have been associated with, is that they have been courses in mathematics, rather than courses in engineering. What is lacking is an awareness of the requirements of the world. One indication of this is the complaint that the graduates know nothing about standards and discipline.
McIlroy: With Fraser I am concerned about the connection between software engineering and the real world. There is a difference between writing programs and designing bridges. A program may be written with the sole purpose to help write better programs, and many of us here have spent our life writing programs from this pure software attitude. More than any other engineering field, software engineering in universities must consciously strive to give its students contact beyond its boundaries.
Galler: I would like to include under education the continuing education of professional people in the field, stressing an awareness of what others have done. I am appalled at the lack of attempts to educate people in what others are doing that we see throughout this industry.
Perlis: Most of the Computer Science programs in the United States, at least at the graduate level, are producing faculty for other Computer Science departments. This is appropriate, because we must first staff these departments. But it is also the case that almost all the Computer Science departments are turning out PhD’s who do not do computer software engineering under any stretch of that term’s meaning. You have to look hard to find anything that is dedicated to utility as a goal. Under no stretch of the imagination can one say that Computer Science, at least in the United States, is fostering software engineering. In the United States National Academy of Sciences Research Board one education committee being formed is precisely to study software engineering as a possible engineering education activity. NATO would probably not be making a mistake in holding another conference within the near future concerning software engineering education.
7.3. SOFTWARE PRICING
7.3.1 INTRODUCTION
A special session on the issue of software pricing was arranged in response to the generally expressed feeling of the importance of this topic in relation to the whole future of software engineering. During the session it became clear that one of the major causes of divergent views on whether software should be priced separately from hardware was the fact that people had differing aims and also differing estimates of the possible effects of separate pricing. The session is reported below by summarising the arguments put forward by various people for and against separate pricing, and about the desirability of preventing