In Fall 2010, my department is introducing a new course, CS222: Advanced Programming. The role of this course is to bridge the introductory programming sequence with development-heavy upper-level coursework. It is in the cards that I shall be teaching the inaugural offering of CS222. I’ve been keeping my eyes open for ideas to incorporate into this class.
I’m reading and thoroughly enjoying Ship It, from the Pragmatic Bookshelf. In fact, I’m contemplating using it, The Pragmatic Programmer, and Effective Java as textbooks for the course, though I need to spend more time planning out how that might work. Ship It spends a chapter on Tracer Bullet Development, and I have already shared an overview of this methodology on the CS345/545 course blog. In writing that post, I came across an interesting article on Tracer Bullet Development vs. Extreme Programming by Martin Ankerl. The two approaches are significantly different, with TBD encouraging some upfront design (though accepting the agile principle that interfaces will change) and XP encouraging evolutionary design (primarily user story and test-driven).
Either of these are good candidates for CS222, in my opinion. An advantage of TBD, pointed out by Ankerl, is that it facilitates parallelization. I certainly want CS222 students to learn how to work in teams, and so having a methodology that makes it easy to break pieces off for different developers is very important. However, TBD also requires some savvy with design, and the students will be coming fresh out of CS2. Software design—in the software engineering sense—is not a major topic of CS222. Learning-by-doing is important, but there is a simple elegance to scenario-driven design in XP. Unit testing and test-driven development are elements that I would like to explicitly include in 222, and so that makes me lean towards XP.
Fall 2010 looks like a lifetime away from here, but I have started keeping more notes on what I’d like to do with 222. These include: effective use of the IDE; interactive debugging; test-driven development; scenarios and user stories; how to read technical books; and the differences between CS1/2-style programming and writing real software. I had thought about trying to get a GA to make this a real qualitative research study, but I don’t think I’ll have the time to get that together.
I’m happy to hear your thoughts in the comments below, kind reader. For BSU-affiliated folks, I am planning on soliciting feedback from current students (e.g. ask current juniors and seniors what they wish they had learned in their sophomore year regarding advanced programming topics) as well as alumni. I’ll probably use our nifty new Facebook group for that.