Prof. Bertrand Meyer

Diese Seite existiert nur auf Englisch!

Course: "Introduction to programming"

Teaching introductory programming has probably always been hard, but it’s even more of a challenge nowadays. The students exhibit a wide range of expectations and initial abilities. They belong to what has been called the "Nintendo generation". Bertrand Meyer talks about this and other challenges in an interview with Ruth Bürkli.

12 July 2004

Your research area is software engineering. What exactly is software engineering?

Software engineering is about building high-quality software systems — systems that meet the expectations society places on them.

You teach the course “Introduction to programming”. Do students learn how to build high quality software in that course?

The course is a preparation for software engineering. Since we teach students how to program, we might just as well teach them how to program well.

For how long have you been teaching this course?

Once so far; I’ll be doing it again starting this October.

Is it easy for students to learn how to program and to understand what programming is about?

Teaching introductory programming has probably always been hard, but it’s even more of a challenge nowadays. The students exhibit a wide range of expectations and initial abilities. When I started programming, no one knew anything about the topic; today computers are everywhere, and people have many opportunities to discover some form of programming on their own. So on the one hand we get some students with a lot of experience in programming, even if they haven’t learned it formally. At the other end of the spectrum we see students who have barely touched a computer before. How do you address such a wide student range? One technique is to start very quickly, assuming that most students already know the basics, and those who don’t must catch up quickly. But this is unfair to the second category; there are students who might become very good at programming when given the chance, but who just don’t have any experience yet.

Another challenge is the tension between providing students with techniques that will be immediately useful when they graduate, and teaching them deeper concepts that will serve them throughout their career. We focus on concepts, since that’s what an education at ETH is about; but we cannot ignore technology, and must introduce students to tools and techniques that are contemporary and up to date.

What other courses do students have to take in the first semesters?

One of the characteristics of the ETH curriculum is that in the first two years students take courses over a broad range of science and engineering topics, not just computer science. In the first semester “Introduction to Programming” is the biggest course, but it’s the only one that’s strictly about computer science. Others include math courses about analysis and probability, as well as logic, taught by Robert Stärk with a strong computer science focus, and linear algebra taught by Walter Gander. Whenever possible we try to make cross references between these courses, to avoid redundancies and give students a sense of unity. For example a good deal of what Robert Stärk teaches about logic is directly useful for my course; and it’s nice to make an occasional reference to numerical algorithms as taught in linear algebra.

Over the first two years there is a whole series of programming courses which used to be known as Informatik I to IV. Informatik I is now “Introduction to programming”; the one which directly follows is now called “Data Structures and Algorithms”, a key course in any programming curriculum. It’s currently taught by Peter Widmayer. We are trying to coordinate closely so that the students can see continuity. For example, we’re both using Eiffel as a programming language. After that there is a new “functional programming and formal methods” course, to be taught by David Basin and Jean-Raymond Abrial. The last course in the series, in the fourth semester, is called Software Architecture, which I will teachin its new form for the first time next year.

So it must be important that you are in constant exchange with the professors who teach these mandatory courses.

Yes. Coordination is important, and we can still do better. On the other hand, it’s good for the students to be exposed to professors with various styles and interests.We have to strike a proper balance betweenconsistency and individuality.

Could you tell us a bit more about how you teach “Introduction to programming”?

It’s quite different from what most institutions do. The course is still new and evolving, but the results from the first instance are extremely encouraging. Among the challenges that we face in teaching introductory programming is how to introduce students to the real difficulty of building software: scaling up to big systems. As long as you’re writing small programs, just about any method will work, kind of. The real difficulty lies in producing complex and ambitious systems, often variants of systems that already exist. It is difficult to teach this in a university context. On top of that we have to keep the students interested, which is made even harder by the diversity of their backgrounds.

Our students belong to what has been called the “Nintendo generation”. They grew up with video games and are used to powerful graphics and multimedia. Traditionally these are not the kinds of examples introductory courses can use.

Another challenge is how to convey that when dealing with significant software systems, there’s no other way than to take an abstract external view of software elements, distinguishing carefully between specification and implementation. That idea, simple as it seems on the surface, is part of what distinguishes the professional software engineer from the casual programmer, and is difficult to teach just in theory. Students have to experience it in practice. For that they must be confronted with fairly big software systems, in particular with software elements that have been written by someone else. Then they realize what it takes to understand maybe 200’000 lines of code.

How did you deal with these challenges?

We’ve gone for a component based approach. At the beginning of the course, we give students an exisiting software system, the TRAFFIC library. Written in Eiffel, it has several tens of thousands of lines of code and several hundred classes. The application domain, interesting on its own, is traffic in a city. Using TRAFFIC you can display the map of a city and its transportation network, and have animations of people following various routes, define new routes and so on.. It is a full-fledged traffic simulation and visualization system. The TRAFFIC library comes with two examples: “touch” is the application that accompanies the text book ”Touch of class” and supports the examples described in there. “flat_hunt”, the second application, is a game and is used as a rich source for exercises that the students of Introduction to Programming will solve.

This is a lot of software! The idea is that students have to understand it from the outside first, which forces them into learning the abstraction mechanisms, and then little by little they can understand how it is done internally. Ideally, at the end of the semester they should be able to build such an ambitious system themselves. We call this an “outside-in approach” to software construction: start from the outside, as a consumer of existing software elements, and little by little learn to become a producer.

The surprise is that it works: by concentrating on abstract interfaces known in Eiffel as “contracts”, you can actually use a powerful software element effectively, without reading its posslby huge source code, which for a beginner would be too hard anyway. This enables us to demonstrate the benefits of abstraction in practice, rather than through preaching.

What are your experiences with this approach? Do the students understand it?

It’s been very interesting! I had thought and written about this approach to teaching for many years. The ideas looked good on paper, but I had never really tried them. So we were nervous to see how they would work out in practice. So far it’s very positive. Having a graphical application with animation and a modern interface suceeds in capturing the students’ attention. They do interesting things right from the first exercise, which already produces a nice animation. I think the students understand what we are trying to do, and live up to it.

Of course we also had some difficulties. Towards the middle of the semester some students complained that because they were always starting from existing components they didn’t know how to build an application from scratch. So I came up one morning without any prepared material and just built a small program on the spot, hesitations and false starts included, not relying on TRAFFIC or any other existing component. Some of the more experienced students complained that they didn’t learn anything new that day, but for the others I think it solved the problem.

Another issue we had is that the TRAFFIC software was new and not quite ironed out. In a way this put the students in a real-life situation — you can’t expect that every tool you use will be perfect — but it caused some problems that could have been avoided. This time around we havehad several more months to continue improving TRAFFIC, so things should be much smoother. Here I should acknowledge the help of a grant from the Rektorat through FILEP, a program that supports innovative educational initiatives; it has been instrumental in producing TRAFFIC in the first place and continuing to work on it. We also benefit from a Microsoft "curriculum grant".

The novelty of the course caused some other problems. I am writing a textbook on the topic (“Touch of Class”, see current draft), and the chapters tended to be ready five minutes before the corresponding lecture. The slides were also not always ready in advance (last year’s slides). As we accumulate experience these problems should go away.

What were the students able to do at the end of the semester?

It was amazing what they were able to produce. They had to do projects, and many of them were quite impressive. One was an addition to TRAFFIC that made it possible to search for events in Zurich, by hooking up to an actual feed from the Internet. You can point to a place on the Zurich on the map and ask what movies play in the area. It was actually quite nifty.

How do you get to know that students have a problem and need for example an extra lecture?

Apart from direct discussions with students, for example during the lecture breaks, much of the information comes through the assistants; they hold 3 hours of exercise sessions per week, as well as office hours. We have a one-hour assistants’ meeting where we discuss what’s going on. This is a good opportunity for the assistants to report how the students are reacting, what they understandi or not.
The form for turning in any exercise or project includes a question asking the students how difficult they felt the work was. Without such explicit feedback it’s hard for the lecturer to know what’s easy, hard, boring, useful.

Do the students get any material about the course?

All the slides — both an English version and a German one — are on the course’s web site, in various formats, normally in advance of the lectures. The textbook “Touch of Class”, in its current state — about half of the final version — is available to the students as well. We also provide ample exercise material.

In addition, we have set up several electronic forums where the students can freely discuss the issues of the course. These forums allow students to ask questions without any fear of looking silly, and provide us with direct feedback.

One of the forums is for female students only. It’s a real shame that we don’t have more girls taking up computer science. To attract more, the department has active programs such as the Schnupperstudium and the Frauenforderung. When we start Introduction to Programming it’s already too late for that, but we should at least help those who are there to succeed.

What actually is the proportion of women?

Around 10% I think. We’re trying to make sure that Computer Science doesn’t look like such a nerdy men-only discipline. There are lots of very successful women in the field.

When is the exam?

It takes place in September. It’s the block exam that is imposed by the ETH system. During the course we have homeworks and a project. These are not taken into account for the grade, but students need to do them to obtain the “Testat” that’srequired to take the exam. To get the Testat you don’t have to solve the problems successfully, simply show that you have seriously attempted to do the work.

Is creativity required for a computer scientist?

Good computer scientists are very creative people. You need to be able to think outside of the box. You need to have a few crazy ideas once in a while, and then you need rigor and logic to weed out the bad crazy ideas from the good crazy ideas.

Where do mathematics come in?

For good software engineering we need a mathematically trained mind, as the rigor of mathematics provides the irreplaceable discipline. Computational science requires calculus in the classical sense — analysis, algebra; for general programming the specific mathematics we need is mostly logic, combinatorics, set theory. It’s a form of mathematics that fundamentally emphasizes clear logical reasoning.

Another originality of our introductory course is that together with the very practical emphasis on things like graphics and animation we put a lot of weight on systematic, mathematically approaches. For example the course relies on math-based concepts of “Design by Contract”; and the very first time students encounter loops, they learn the concept of loop invariant, which elsewhere is often taught only in advanced theoretical courses, but in fact greatly enhances understanding even at an elementary level.

Why should anyone study computer science?

Computer science is still one of the most exciting areas of human knowledge today. You get to build all the machines you want to build; the only contraint is your imagination and to a lesser extent the available hardware. The machines we build are pure products of our thinking; they don’t weigh anything, so you can carry them from the basement to the top floor without any effort; they won’t hurt your feet or stain your clothes if you drop them, and won’t break by themselves. It’s kind of … well, the dream of humankind of building any machine you can imagine. It’s the old Golem idea. I don’t know anything that is as exciting intellectually— molecular biology or genetics maybe?

Is this why you became a computer scientist? You wanted to build machines?

Sure! The first time you write a program and, more importantly, the first time you write a program that runs, which is usually some time later, there is this impression of magic. You thought of something, and it worked! Every time this happens I’m still flabbergasted. Just the intellectual excitement is enough to devote an entire career to this. Besides, it pays pretty well.

How do you see the chances for students to get a job after their studies in times when big companies outsource their IT divisions?

Of course there was this IT bubble between 1996 and 2000 which burst. To a large extent the bursting was healthy. Too many projects got funded which did not deserve it,. But despite this temporary downturn, the general direction of the curves remains up. It is true that these days a lot of the development is being outsourced to countries like India, Russia, or China. They have been quite successful at combining good education with low prices. But of course this doesn’t mean that one should spurn IT. The phenomenon of outsourcing also confirms that we need ever more systems, and people to specify and design these systems. Someone needs to define what the software will do, understand how it relates to the business of the company, ensure the integrity of the design, and verify that the delivered product conforms to the real needs of the customer; much of this can only be done within the company itself. Pure implementation jobs will increasingly be outsourced, but systems thinking is irreplaceable.

Do you account for this in your teaching?

These industry trends are directly relevant. We should not be training people with a low-level, narrow focus on specific technologies. What we want to teach is system thinking. We need people having the big picture, who are not just coders but can do analysis, design, quality assurance, documentation, people who master the overall picture, as required to have a successful career in industry. The ETH curriculum provides this kind of training, so I don’t think students need to be worried about their future in the IT industry.

In the past year I have become fascinated by this phenomenon of offshore development, which I see as a revelator for all the issues of software engineering. When half of your development team is in Bangalore and the rest split between Zurich and Saint Petersburg, some problems take on a full new life: requirements engineering, quality control, documentation… With Peter Kolb, then from ABB, we set up an industry course on the topic, which we are giving again in November, and also a graduate course at ETH. We’re also working on a book on the topic.

Do you think ETH is a good place to study computer science?

We don’t just teach Java or XML or UML or some particular technology which might land you a job right after graduation but not a profession. We attempt to equip students with the long-term analytical skills that will make them indispensible for many decades to come. That’s the distinctive trademark of ETH.

You think ETH is a good school not only because of the teaching, but also for its research?

I guess we could start another interview about this. The combination between the best teaching and the best research is what has made modern science possible, and is what makes a university and in the end a country successful. ETH is one of the places thatapplies the formula.

Is there anything special you would like to say to our students or future students?

Perhaps just this. Computer science is a very rewarding field in many ways, including material ones. In a university setting what should dominate everything is the sheer intellectual excitement. The field is full of fun, of surprises, of unsolved problems. It’s still growing every day; there’s almost no limit to what you can learn and invent. Keep your eyes open for new challenges, and seize them.