I recently read a fascinating post by Joel Spolsky entitled “Capstone projects and time management”. It’s highly opinionated, as usual, but makes several interesting points about teaching computer science in academia.
He basically claims that academic computer science doesn’t teach you to use modern tools, or do version control, bug tracking, teamwork, planning, etc., etc., etc. He repeats his frequent assertion that the academic world is almost completely divorced from the real world of software development.
I imagine he’ll get a ton of responses to his post, which is fine. Somebody needs to whack the beehive every now and again, and I’m glad this time it won’t be me.
(I’ve been bumping into beehives lately, which is unfortunate. I like causing trouble, but I hate getting into trouble, and I’m doing way to much of the latter. Maybe it’s my premature entry into curmudgeon-hood. Ginger thinks it’s way too early for me to be turning into such a grumpy old man. But, you kids, get off my lawn!)
At any rate, most people who follow my blog are aware that my regular job is teaching software development training courses. Roughly once a year, though, I get to play at being a professor at Rensselaer Polytechnic Institute in the Education for Working Professionals program in Hartford, CT. That’s formerly Rensselaer at Hartford, formerly the Hartford Graduate Center. In the late ’90’s I got my MS in CS there, at night, while I was transitioning from my career as a research scientist into my current business.
I teach a class called “Developing Enterprise Applications”*
*So all of our programs work on the library computer on a starship (rimshot).
The basic idea is that I try to show the students the current state-of-the-art in software development, based on my experiences. Since I teach a lot, I can travel to 20 to 40 different companies a year. That gives me a decent sense of what’s going on around me, along with blogs, podcasts, twitter feeds, and participating in the Groovy and Grails open source projects.
I’ve taught my Rensselaer class about half a dozen times so far, and it’s been completely different each time. Most recently I taught it last spring (2009). We talked about Spring and Hibernate, used a Subversion server to check in code (actually a Google code project, but that’s the same thing), ran lots of JUnit tests, added Ajax capabilities with prototype and script.aculo.us, and briefly went over, of course, Groovy and Grails. I write code during class which the students are free to use, and I keep notes on Google Docs, which I share with them.
Here’s the cool part, though. There are no assignments, no exams, and no homework of any kind, with one exception. At the end of the course, the students have to present an application they’ve written to the rest of the group.
The choice of project is completely up to the individual student. I do give them a list of requirements, which are negotiable until about half-way through the semester. Here’s a portion of this years’ list:
- Use a framework (Struts, Spring MVC, JSF, Grails, RoR, or other)
- Create an ORM layer (Hibernate, JPA, roll-your-own)
- Test as much as possible (unit, integration, functional)
- Ajax capabilities are a plus
- Do something with web services (REST or SOAP; at least consume, generate if possible)
- View templates are optional but preferred (Velocity, Freemarker, Sitemesh, whatever)
I’m quite flexible on the actual implementations, as long as the student clearly learned something and the implementation has some value. Students can write in Java (most of my demos are in Java, so that tends to be a favorite), or .Net, or anything else they prefer, as long as they try to fulfill the requirements above.
My favorite requirement, however, is the Design Document. This is very important to me because I want the students to tell me what worked, what didn’t, what they liked, and what they didn’t. I want this to be a low-pressure opportunity to experiment, and if they’re truly experimenting, then not everything will succeed. I want to know what they tried, even if it failed.
I do ask that one use case has to work. I’m fine with experimenting, but there’s nothing like working code to motivate you. Students (like most developers) tend to way overestimate how much they’ll actually finish, though, so I only ask for a single case to function correctly.
Regarding teamwork, I allow them to work in groups of one or two only. My experience has been that groups of three or larger don’t finish in time, or one student winds up doing too much of the work. I like the idea of doing a team project, but I haven’t figured out a good way to manage it yet. Two person teams tend to work, both in scheduling and production. Most students prefer to work by themselves. I’m fine either way.
During the last class, each student (or group) hooks up their laptop to the projector, demonstrates the application, and then walks through the code. I bring the donuts and coffee, and we all watch together and ask questions.
Then I give out the A’s. If you clearly tried something ambitious, and you clearly learned something, and you fulfilled the deliverables above, then why not? I only give out A’s and F’s, and the latter only happens if a student clearly left everything until the last minute, never came to class, and then tried to snow me with a rushed project. My rule of thumb is that if I could do your entire project in a couple hours, you didn’t do enough*. I get a student like that about once every other year.
*Of course, I have to pretend I don’t know Grails when I say that…
I find this a very easy, successful way to teach, and the students seem to like it too.
Leave a Reply