Waterfall? Spiral? Who cares?

When I graduated with a CS degree, lo these many years ago, I had no idea how software was actually built, despite several quarters of “software engineering” courses. These classes covered the classic “waterfall” model, in which a list of requirements leads to an architecture leads to coding leads to testing leads to release (and woe be to the project that does these out of order or interspersed) and also the slightly newer “spiral” model, in which a little bit of requirements analysis leads to a little bit of architecture leads to a little bit of coding leads to a little bit of testing leads to more requirements analysis and so on until you’re dizzy.

So I went out in to industry, and discovered that how software is actually built has nothing to do with a waterfall or a spiral. It is, in fact, much messier.

The spiral model is, however, the basis of Scrum and XP and other agile methodologies, in which you do a little bit of work, make sure everything’s OK with your customer, change direction if necessary, repeat until you’re done. What agile methodologies add to the spiral is the explicit acknowledgment that creating software is a social act. Communication at the right time with the right people often makes the difference between building the right product and building the wrong product.

The waterfall and the spiral and other formal models such as the “surgeon” don’t model real-world software development very well because they ignore the impact of communication skills. The agile methods do not. XP, for example, sets up a formal channel of communication between the customer and the programmers. It also sets channels within the programming team via pair programming, nightly check-ins, and automated builds.

I recently started reading current academic papers on software engineering again, and discovered that many researchers still use the process model of “requirements -> architecture -> coding (repeat as necessary).” They think it is how software is built. They look for ways to improve a particular phase of that process.

In general, they completely miss the social aspect of software production, which is really what determines whether a project succeeds or fails. Creating software is inherently a chaotic event that depends on forces we can’t (currently) model formally. Perhaps they’re uncomfortable with something they can’t reduce to a diagram, but if they continue to ignore it, the gulf between what academia thinks we’re doing and what we’re actually doing will continue to grow.

This blog entry was posted on Thursday, February 15th, 2007 at 12:56 pm and is filed under Design process, Thoughts. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.