Pretty image
Life isn’t fair, information is never complete, and goals change in mid-project. So why does programmer education pretend otherwise?

An issue that many of us struggle with is the fact that some developers “get it” and some just don’t. The “it” that is or isn’t gotten varies. Some developers never really understand threading, others never grok agile, others never accept test-first development.

I’ve thought a great deal about one of these not-get-its: the inability of lots of developers to understand the notion of shifting requirements and the need to design software with that notion in mind. We’ve probably all seen developers who won’t write a line of code until the Requirements Document has been written and blessed.

Back to School

I think that a primary cause of this mindset is our university courses. If you set the Wayback Machine and remember your Programming Projects class you may see what I’m talking about. Or you can take a ride in my Wayback Machine....

At my school we developed a plan for a semester-long programming project. The entire class consisted of (1) defining the problem and then (2) implementing the solution. The notion that the problem might change midstream, as so often happens in the real world, was never even brought up. If anyone had brought it up, I think it would have been considered heresy.

In most (all?) university classes, the assignment is pretty much cast in stone once it is assigned.

I suggest a much different type of project class. In this class students are given a series of assignments but are also given the heads-up that the assignments might change at any point. I’d envision the following set of “surprises”:

  • an assignment is scheduled for four weeks, but three weeks into it, you demand a “customer” demo of whatever code has been written so far

  • halfway through the assignment you remove a significant requirement

  • halfway through the assignment you add a large new requirement

  • the assignment is clearly too large for the time allowed, and you tell students they’ll find out which parts are mandatory several weeks into the assignment

Some students might try to game the system waiting to code anything. These students would be trapped by the first surprise. Other students might build a rigid system and get trapped by the second surprise. Still other students might build a limited system and be trapped by the third surprise.

The successful student would use the knowledge that the requirements would change and would design a flexible system. These students might be pretty rare but they’re the ones I’d like to work with.

Back in the Wayback Machine again, if you please.

Moving Target

About that semester-long programming project at my school: My project was a little unusual. My team implemented the timing and scoring software for the Head of the Connecticut Crew Regatta. We had a very clear deadline: the date of the race was unmovable. On the other hand, we quickly learned that many things were going to be fluid. The number of races, the number of racers, and the order of the races was going to change until right before the race date.

We also knew that as the official scorers we needed to provide challengeable results. To that end we stored all raw result data in human-readable form. We also provided a very simple and flexible user-input system. This was put to the test during the actual race.

The regatta was going fine until the Finish Line buoy got cut. Suddenly the finish line started drifting down river! A contestant approaching the finish line shouted to the scorers on the river bank “what do we do?” We told them, “keep rowing!” and captured several alternative “finish times” for that boat. That was not a scenario that we had in any way anticipated, but the flexibility we had designed into the system accommodated this unexpected event.

So that’s my simple proposal: changing goals in student projects. I think that if more students had exposure to real-world projects—or at least projects whose requirements changed midstream—we would end up with better engineers.

Brian Tarbox is a Principal Staff Engineer at Motorola where he designs server side solutions in the Video On Demand space. He writes a blog on the intersection of software design, cognition, and Tai Chi at briantarbox.blogspot.com.

Send the author your feedback or discuss the article in the magazine forum.