A Student-Oriented Software Development Process

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. Teams are small, transitory, have little expertise in the application domain, and are in effect geographically distributed.
  2. The client is relatively inaccessible.
  3. The spec is both rigid and incomplete (sorry, but that is a good description of most assignments).
  4. There is only one opportunity to release each feature (i.e., any piece of work is only graded once).


In the wake of posts about Shopify's support for white nationalists and DataCamp's attempts to cover up sexual harassment
I have had to disable comments on this blog. Please email me if you'd like to get in touch.