TITLE: Initial Thoughts on Teaching Software Engineering AUTHOR: Eugene Wallingford DATE: December 14, 2009 8:45 PM DESC: ----- BODY: We have entered finals week, which for me mean grading team projects and writing and grading a final exam. As I think back over the term, a few things stand out. Analysis. This element of software engineering was a challenge for me. The previous instructor was an expert in gathering requirements and writing specs, but I did not bring that expertise to the course. I need to gather better material for these topics and think about better ways to get help students experience them. Design and implementation. The middle part of my course disappointed me. These are my favorite parts of making software and the areas about which I know the most, both theoretically and practically. Unfortunately, I never found a coherent approach for introducing the key ideas or giving students deep experiences with them. In the end, my coverage felt too clinical: software architectures, design patterns, refactoring... just ideas. I need to design more convincing exercises to give students a feel for doing these; one big team project isn't enough. Too much of the standard software engineering material here boils down to "how to make UML diagrams". Blech. Testing. Somewhat to my surprise, I enjoyed this material as much as anything in the course. I think now that I should invert the usual order of the course and teach testing first. This isn't all that crazy, given the relationship between specs and tests, and it would set us up to talk about test-driven design and refactoring in much different ways. The funny thing is that my recently-retired software engineering colleague, who has taught this course for years, said this idea out loud first, with no prompting from me! More generally, I can think of two ways in which I could improve the course. First, I sublimated my desire to teach an agile-driven course far too much. This being my first time to teach the course, I didn't want to fall victim to my own biases too quickly. The result was a course that felt too artificial at times. With a semester under my belt, I'll be more comfortable next time weaving agile threads throughout the course more naturally. Second, I really disappointed myself on the tool front. One of my personal big goals for the course was to be sure that students gained valuable experience with build tools, version control, automated testing tools, and a few other genres. Integrating tool usage into a course like this takes either a fair amount of preparation time up front, or a lot more time during the semester. I don't have as much in-semester time as I'd like, and in retrospect I don't think I banked enough up-front time to make up for that. I will do better next time. One thing I think would make the course work better is to use an open-source software project or two as a running example in class throughout the semester. An existing project would provide a concrete way to introduce both tools and metrics, and a new project would provide a concrete way to talk about most of the abstract concepts and the creative phases of making software. All this said, I do think that the current version of the course gave students a chance to see what software engineering is and what doing it entails. I hope we did a good enough job to have made their time well-spent. -----