What's in a Name?

In response to some comments in another interesting post on Stuart Lynn's blog I asked if we could stop using "Waterfall" as a generic term for "non-Agile" processes.

Guy Letts then asked me the rather obvious question via Twitter:

Your suggestions for a better term...?

The short answer, that I gave Guy, was "Traditional".
Here's the long-winded version!

Waterfall was originally (at least according to wikipedia <ahem> <poor research>) described by Dr. Winston W. Royce as an example of a deliberately flawed and broken system.
In my own university days, it was used as a teaching method to identify the stages of the software project life-cycle, but even then it was made clear that this wasn't a practical approach to use in the real world.

The problem with using the term "Waterfall" like this is that the flaws of the method are obvious. This invites the straw-man attack from those pushing an Agile agenda - "Waterfall is bad, therefore all similar approaches are also bad".
This is just as divisive and unproductive as the "it's all code-and-hack-and-fix" claims of the Agile-skeptics.

As it happens, and as I'll discuss in a future post, I think that the differences between the two approaches aren't as great as some people would have us believe. I think that applying generalised labels can create mind-sets which inform thinking and lead people to believe they have to take "sides". This is potentially harmful and benefits no-one but the guys with books to sell!
We should be able to look at all the tools available to use and choose the appropriate set for the job we have to do and the people who will be doing it.

That said, I started this, so...

A term that's commonly used in Agile circles is "Big Design Up-Front".
That's nice and descriptive, but has several drawbacks:

• It's a bit of a mouthful
• It tends to be used in scathing tones that imply all up-front design is wasteful. Which is ludicrous
• It abbreviates to "BDUF", which sounds vaguely insulting

Again, there's an implicit assumption that Agile approaches are inherently better and that it's "wrong" to use anything else. That might be great if your audience is already in the club, but it's not an approach likely to win hearts and minds!

So why do I like the term "Traditional"?
What I really like is that it balances the positive and negative implications nicely:

• It recognises that there may be newer alternatives that may have advantages
• It doesn't imply an assumption that newer is always better. These methods have been used successfully for many years; they have been refined over time and many people are attached to them.

Introducing new approaches, we need to be certain that we understand the value of existing practices and ensure we're not losing anything.
We need to be aware that logical arguments aren't effective for addressing opinions based on long experience or emotion.
And we need to understand that insulting people doesn't help!