During the past Winter/Spring term, I lectured a course on Software Engineering for the Electrical and Computer Engineering Department at the University of Toronto. Although I’d been a part-time high school teacher for more than three years, this was my first time lecturing at the undergrad level, which in my case meant that I wanted to try a lot of things. Though some worked, others fell flat. I want to share them with you here. It’s been about three and a half months since I handed in the final grades, which means it’s very late for a postmortem, but better late than never:
- Previous incarnations of the course reflected heavily the interests of their lecturers, and I was unhappy with some of the material available. I chose to borrow as much material as I could from other courses not usually available to ECE students (in Software Engineering, Software Architecture, and Requirements Engineering), mix it up, and fill in the gaps with some ideas of my own.
- In the end, you could divide the lecture side of the course in two sections. The first concerned with high level software engineering and project management issues (from discussing why do we even call this “software engineering”, to eliciting requirements and estimating effort). The second section was almost exclusively focused on architecture and design issues, and more specifically in design patterns.
- The assignments side of the course consisted mainly of two team activities. First, every team had to make a contribution to a relatively mature open source project. (This was modeled after a similar exercise by Daniel German, at the University of Victoria.) And second, following a similar course by Greg Wilson, every team had to compare the architectures of two similar open source projects.
- There were 25 students. For the first half of the course we didn’t use any textbook. For the second half we followed the Gang of Four’s Design Patterns book (perhaps too) closely.
- The two assignments clearly helped students find out how software architecture and development happens in the “real world”, and this was evident in their reports. Since the open source assignment required them to have a patch accepted by a mature project, they needed to explore, contact, and negotiate with established development communities. The other assignment –the architecture comparison– allowed them to study how different teams tackle similar architectural challenges.
- I made an effort not to fall in the trap of the standard software engineering textbooks, which often present as truth that which is at best questionable practice. I tried to be as candid as possible. For example, I complemented the lectures on software estimation techniques and software process methodologies with discussions on their limitations. I also tried to be practical –pointing out those practices that have been tried, tested, and easy to use: prototyping and simple requirements elicitation techniques, for instance. I think these efforts paid off.
- The open source contribution assignment turned out producing some very weak contributions. This was my fault: I had the final say on whether a proposal was ambitious enough, and several were not. As a result, some teams had it way too easy.
- We covered every single design pattern in the GoF book. This was unnecessary and confusing. You don’t need to study all 5 creational patterns in one go, anything beyond Factory Method and Abstract Factory is superfluous in our context. Same goes for the other kinds of patterns. Each pattern ate about half an hour of our time –not enough to learn it, certainly not enough to master it.
- As a result, towards the end, the lectures were too dry and boring. There’s only so much excitement you can draw from the next two design patterns in the list.
- I got sidetracked telling anecdotes and horror stories, more than I’d like to admit. I’ve noticed this defect of mine before; I did almost nothing to correct it.
If I were to do it again…
- Both assignments were brilliant as ideas, but mediocre in their execution. The open source contribution assignment is gritty and useful, but the bar for acceptance needs to be raised significantly. The architectural comparison assignment needs to be based on projects with complex and elegant architectures, with supervision from a qualified TA, for students to really learn from the best.
- In lectures, I’d drop about 70% of the patterns from the GoF book, and focus on exploring in depth the few remaining, and in discovering their application in seemingly disconnected domains.
- I’d cut time on architecture and design, and add one or two lectures on testing and quality assurance.
- I’d bring a couple of guest lecturers from industry to talk about real-world software development practices and priorities.
If YOU are thinking of doing it…
- Know that a course like this will eat about 20-25 of your most productive hours, every week, for four months.
- Know that many engineers have problems with subjective marking.
- Try and contact your TA well in advance, so that he/she can help you coordinate the tutorials and lab sessions.
Hope this will end up helping someone.