General Comments on Lectures

I find the subject of software engineering endlessly fascinating, and get a great kick out of successfully solving a programming problem. The down side is that this subject can be almost equally endlessly annoying and frustrating, particularly when you are trying to come to grips with it for the very first time. This course has been evolving over the past several years, but one basic principle has remained constant: I see my role not as a teacher or instructor, but as a facilitator.

The reason is that software engineering is a subject which is dominated by doing. It cannot be primarily learned by listening or reading, though both of these can play a subsidiary role; it must be learned by taking control, and doing. The frustration of the subject lies in the fact that, particularly at first, this doing is necessarily uninformed and feels very much like thrashing around in the dark - and will frequently end in failure; but the joy lies in the fact that the failures are always ultimately understandable and correctable - and this understanding and correction delivers tremendous satisfaction.

Given this emphasis on doing, I consider the time you will spend in the laboratory (both scheduled lab sessions, and private study time) as being the most central and important component of the course. Nonetheless, a small lecture component is still useful to complement this practical work, and to provide overall structure and pacing to the course.

There are two scheduled lectures and one tutorial each week. In practise, I expect all three sessions to be tutorial in nature. This reflects an increasing emphasis on active, personal, study time. The lectures will closely follow the textbook. I work on the assumption that you will have studied the assigned material in the textbook, and any related notes provided here, before each lecture. In this way the lecture sessions can be interactive in nature.

Note that attendance at lectures for this course is monitored. While it is entirely under your own control and discretion whether to attend or not, information collected on attendance will be made available to the examination board and may be taken into account in considering borderline decisions.

Delivering the lectures on this basis has several significant advantages:

• I am relieved of the tedium of presenting extensive, repetitive, and usually rather boring, notes in the lectures.
• Perhaps more importantly, you are freed of the tedium (not to mention writer's cramp) of transcribing them.
• The lectures can be used to allow discussion, clarification (and sometimes even correction!) of the textbook material. Further, should you choose to play an active role in the lectures, they can be used to explore those topics which you find particularly interesting or difficult in more detail.
• Since all the written materials for the course are available to you independently of attendance at lectures, you can decide for yourself whether or when it is worth your while to attend the lectures. For example, if you happen to already be proficient in certain aspects of software engineering, and are satisfied that you completely understand the assigned materials, then you may well decide to miss certain lectures and allocate the time for some other, more pressing, studies. However, I recommend that you adopt this position only with extreme caution!
• Conversely, should you miss a lecture for some reason outside your control, or otherwise fall behind in the course, then because the written materials are all available to you you will have the flexibility to schedule in extra study time to make up.

In summary, my intention in designing this course is to empower you, the student. That is, I hope that you will be able to enjoy and benefit from this course precisely in proportion to the energy and effort you are willing to invest in it. No more, no less.