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.

<EM>Analysis</EM>.  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.

<EM>Design and implementation</EM>.  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.

<EM>Testing</EM>.  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.
-----