Mile
Zero

August 28, 2014

This fall, I'll be teaching ITC 210 at Seattle Central College, which is the capstone class
of the web development program there. It's taught as a combined class with WEB 210 (the
designer's capstone). The last time I taught this course, it didn't go particularly well:
although the goal is for students to implement a WordPress site for a real-world client,
many of them weren't actually that experienced with the technology.

More importantly, they had never been taught any of the development methods that let teams
work together efficiently. I suggested some of the basics — using source control,
setting tasks, and using a "waterfall" structure — but I didn't require them, which
was a mistake. Under pressure, students fell back on improvised strategies, and many of them
ended up in a crunch as a result.

For the upcoming quarter, I plan to remedy those mistakes. But to do so, it's helpful to
look at the web development program from a macro level. What is that we're trying to do
here, and what should this capstone class actually mean to students?

Although the name has changed, Seattle Central is still very much a community college, and
this is very much a trade program. We need to focus on practical job skills, not on CS
theory. And so while the faculty are still working on many of the details, one of our goals
for curriculum redesign was to create a simple progression between the three web
applications classes: first teach basic programming in ITC 240, followed by an MVC framework
in ITC 250, and finish the process with a look at development processes (agile, waterfall,
last-minute panic, etc.) in ITC 260. By the end, students should feel like they can take a
project from start to finish as part of a team in an organized fashion.

Of course, just because that's what our intentions were doesn't mean that it's working out
that way. These changes are large shifts in the SCC curriculum, and like steering an
Oldsmobile, those take time. So while it would be nice to assume that students have been
through the basics of project management by the time that they reach the capstone, I can't
count on it — and even then, they probably won't have put it to practice in teams,
since the prior classes are individually-graded.

To bring this back to ITC 210, then, we have two problems. First, students don't know how to
manage development, because they've spent most of their time just learning how to code.
Second, the structure of the class hasn't historically encouraged them to develop those
skills. Assignments on the development side tend to be based around the design milestones,
which makes their workload "lumpy:" a lot of waiting for design resources, followed by an
intense, panicky burst at the end. This may sometimes be an accurate picture of the job, but
it's a terrible class experience. Ideally, we want the developers to be working constantly
throughout the quarter.

So here's my new plan: this year, ITC 210 will be organized for students around a series of
five agile sprints, just like any real-world coding project. At the start of each sprint,
they'll assign time and staff to tasks, and at the end of each sprint they'll do a
retrospective to help determine their velocity. Grades will be largely organized around
documentation of this process. During the last sprint, they'll pick up another team's site
and file bugs against it as QA, while fixing the bugs that are filed against them.

This won't entirely smooth out the development process — devs will still be
bottlenecked on design work from time to time — but it will make it clear that I
expect them to be working the entire time on laying groundwork. It'll also familiarize them
with the ways that real teams coordinate their efforts, and it will force them to fit into a
common workflow instead of fragmenting into a million angry swarms of random methodology.

I tend to make fun of programmers for thinking that they're the only ones who can invent a
workflow, but it's easy to forget that coordinating a team is hard, and nobody comes by it
naturally. I made that mistake last time around, and although we scraped by, there were
times when it was rough. This quarter, I'm not giving students a choice: they'll work like a
regular software team, or they'll fail the course. It may seem harsh, but I think it'll pay
off for them when it comes time to do this for a living.