A Student-Oriented Software Development Process
March 6th, 2008
Steve Easterbrook and I were talking last night about the problem of teaching real-world software engineering in a classroom setting, and during the conversation, I realized that the way students are required to work violates several of the requirements for success of both agile and sturdy development processes:
- Every process, from waterfall to XP, will tell you that frequent interruptions increase the odds of failure, but students are constantly required to interrupt work on one course to complete assignments in others.
- I’ve argued before that which process a team uses matters less than having a process and following it, which in turn depends on the team being together long enough to get used to working a certain way. Student teams are together for (at most) some fraction of one 13-week term.
- Even during that time they are rarely collocated—students sometimes work side by side for a couple of hours or an afternoon, but most work is done solo. This means that teams usually work as if they were distributed; again, most processes consider this a risk, and for good reasons.
- Modern processes (such as RUP and XP) emphasize close interaction with customers, but most student projects only have a spec (i.e., an assignment).
So, what would a student-oriented development process look like? More generally, what’s the best development process to use when:
- Teams are small, transitory, have little expertise in the application domain, and are in effect geographically distributed.
- The client is relatively inaccessible.
- The spec is both rigid and incomplete (sorry, but that is a good description of most assignments).
- There is only one opportunity to release each feature (i.e., any piece of work is only graded once).
Thoughts?
I think there’s several things to consider there.
= Process:
I’ve thought several times that adopting a process that somehow emulates the best practices from the open source world would be useful for students. There’s obviously big differences between open source contributions and working on a class project, but there are a lot of similarities too:
- Contributions often come in small discrete pieces
- Development is distributed
Maybe the first assignment of the term (first week) is for each group to come up with it’s own process, they decide how they’re going to do development, and then stick with it. This probably shouldn’t be totally freeform, but have some restricted categories. I think that there should be more individual marking in group projects as well. I’ve often felt that if people’s mark depended more directly on their work, there would be less slacking off.
= Spec:
One of the things that I found about course projects is that students in their 3rd-4th year still feel like they’re not allowed to make choices, while in reality they are. When working on a project students feel like if they don’t do everything exactly like the spec says, they’ll get a horrible mark. What often happens is that the spec gets disambiguated along the way and as long as your design decisions are somewhat reasonable you’ll do reasonably well. But this never gets communicated, and I think if it gets communicated better students will spend less time slaving away at meaningless details, and more time doing things that matter.
= Release
I think it would be very useful to allow students to start developing later assignments early. If all of the assignments are released early enough in the term, students can start thinking about them, and get feedback from TAs and profs. Maybe they won’t mark those parts, but as long as there’s willingness to talk about them, it could be very useful. I found this sort of thing very useful in the compilers course.
Apprenticeships. Sort of.
It’s been over 25 years since I was in that situation but if I remember correctly, our instructor handled it by creating artificially small tasks for us to do. None of the software that we created did anything very complicated so it wasn’t too hard to hack it together in a hurry. So long as we had created a significant portion of the design and code before the next class we could pester the instructor for more information well before the deadline. And because the size of the tasks were small we could always throw away our work and start over without worrying too much about the deadlines.
The most telling thing from the beginning of my career was seeing a fifteen thousand line program for the first time. I sat there with my mouth open for several minutes wondering how such a thing came to be. It was a harsh welcome into the world of programming for money instead of programming for a grade.
The real problem that I see with the four requirements that you list is the last one. The other three are common to real world projects of all kinds. But having to release one and only one time without any feedback is a nightmare scenario. If no feedback with a single release was the norm for our industry I would have changed careers a long time ago. I wonder how many great developers didn’t follow through with their college degree in software development because of just that issue. Grade pressure can change your major faster than you can say “it was the teachers fault”.
So what would a better way look like? I doubt that there is a way to do it within the traditional university formula. The possible exception is the learn/work/learn/work setups (often called co-ops or internships or whatever). The way that I learn how to do something is by doing it, preferably under the direction of an effective trainer/coach. The dumbed down development tasks that you normally work through as a student are merely broken shadows of what IT professionals do on a day to day basis.