Software Engineering Class Brainstorm


Dan and I went in to give our annual lecture to Dr. Michael Young’s Game Design class at NCSU this past Wednesday morning. Every year we give a talk that usually includes how to get a job in the game industry. This year we got a little prompting to add some more flavor to the software engineering side of what we do.

Every year we do a quiz to find out how many people use the tools of the trade. In a class of about 13 people, here were the rough numbers:
Revision control (3 hands)
CVS or Subversion (8 hands) *note the discrepancy with the above count
Bug tracking databases (2 hands) *both seemed to have done QA as interns
A real IDE like Eclipse or Visual Studio (10 hands) *much better than prior years
A profiler (2 hands)

This of course, got me to thinking. I’ve been toying around with the idea of teaching a practical software engineering class for a few months. The idea stems from the fact that I don’t think that the CS curriculum in college does a very good job of educating its graduates. It exposes students to many of the fundamental concepts of the science, but misses out almost entirely on the hands-on practical nuts and bolts of writing code in a team environment. Most of the time that education falls onto the first manager and team that works with the new grad / intern. I know that I learned more in the first 6 months on the job at NDL than I did in my four years of education in college (It could be argued that the four years were necessary to get me to the point that I could absorb that much that quickly, but I’m not sure that I buy that argument). I’ve mentored a handful of interns and fulltime engineers now and I think that I have a reasonable idea of what I’d like them to come armed with on day one.

The rest of this blog post will be the moderately filtered brainstorm from my sleepless night prior to giving the talk, subtitled: How would I create a software engineering class?

Class Premise: You aren’t equipped to really start thinking critically about software engineering practices until you’ve shipped something as a member of a team.

Engineers are generally hands-on folks and are skeptical until they learn the hard way. The biggest value-add that a good team leader/mentor/manager can provide to a new engineer is being there for those “teachable moments,” i.e. be there when a mistake is made and use that as a springboard to help them work through the problem themselves.

How to address this problem: The entire intro to software engineering class is a class project to develop and ship a piece of software. The TA and professor function in the role of manager/team lead. There are still lectures, of course, because the class will be wholly unequipped for what they will be facing. The lectures are meant to introduce the important topics and be a reference point when having those teachable moments.

Start with the basics, how does the team communicate?
Share code via a Subversion server
Share docs via a Wiki
Have conversations/ ask questions via a message board
Share tasks and bugs via Bugzilla or other bug database
In class “scrums” where the first 15 minutes of class are spent bringing up any blocking issues. Doing much more than that will consume the entire class some days, but maybe that’s worthwhile?

The great thing about these methods of communication is that they are all trackable as metrics. If I want to know how much someone is contributing, I can take a look at the methods of communication.

Class Structure
The semester/project is broken into several 3-4 week sprints as per agile methodologies. The team will help plan the contents of each sprint. If two projects are used, perhaps one is standard waterfall and other is agile.

How do the students get a grade?
I’d be tempted to offer this as a pass/fail only course, but here’s a first thought to a grading scheme. Since this is about learning to be on a software team, let’s have performance reviews. I’d like to have 2 per semester. One at the midpoint and one at the end. Students and the professor/TA would fill out a perf review document with scores (1-5) in a couple of functional areas and place to fill in comments per area. Then both would meet and discuss the review. The final grade would essentially be the results of the perf review.

Student assignments
Here are some potential clusters of tasks:
Requirements gathering
Design
Coding
User documentation
Developer documentation
Code reviews
QA Automation
Manual QA
Infrastructure (like Continuous Integration)
Sprint planning
Research into potential technologies/techniques/methodologies

Why should students care?
This isn’t just a lecture where you are talked “at”. You are a hands-on participant that gets out what you get in. If the software is good, it will be out in the wild for you to use on your resume. If it is bad, well.. you can leave that one out.

Misc Questions/Thoughts Brainstorm
Set up as sourceforge or google code project?
How big should the project be?
How much time is each student expected to put in?
How to deal with superstars?
How to deal with nonperformers?
What language? Must use a real IDE and debugger.
One project per semester? What if they do well and finish early? How to choose project? Am I driving feature set or is this for an external customer? (I prefer to drive the feature-set to keep it simple and guarantee proper time/attention)
Do we need team leads? How are they chosen? Do they change every sprint?
Do we break the class into mini-teams based on “role”, i.e. the QA team, Doc team, Dev team? Can we cycle everyone through each team? If not, how do we make sure everyone has a taste of every flavor of task?
Testing and automation needs? Unit tests for every feature? Does the developer write all the tests or do we break out functional testing for QA “role”.
What should the project be? Could we do something mobile? Web-based? Game-based?
I wonder who would come as a guest lecturer?
Who has done something like this before (answer: there are no brilliant ideas in this blog post, so it must have been)? How close to gamedev schools process like Guildhall?
How much bootstrap code? Is it better for them to start tabula rasa or to have some code already on the ground? How many “Easter eggs” should be in the pre-existing code to seed some teachable moments?
In class code reviews? Embarassing for students? Have to maintain professional decorum. Can have code review tasks that are checked in or put on wiki
Code of the week/Bugfix of the week? Praise good contributions. Teach by example, but show ways to improve
Dealing with other people’s code is important. Fight urge to rewrite every time.
Allow student blogging? TA blogging? What about prof?
How does this tie into education research and grant $$$?

Advertisements

~ by shaunkime on March 26, 2010.

One Response to “Software Engineering Class Brainstorm”

  1. […] it could be tackled by one focused course. I've talked about this topic before, but I stumbled on a blog post by ex-Emergent TD Shaun Kime that has me thinking about it again. I honestly only glossed over his […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: