More on Waterfall

Kent left a comment on my Trespasser post that I felt deserved a highlight:

You say “If waterfall is going to work, you need detailed specs.” I’d argue that for any project requiring multiple developers, it’s impossible to write down specs in advance that are detailed enough for waterfall to work. The entire presumption of the waterfall method is that you’re smart enough to write everything down in advance and know how long it will take. But software is a creative process, with even small projects requiring thousands of micro-decisions along the way. All of those decisions interact and cause uncertainty.

Using waterfall for writing software is about as sensible as using it for writing a novel.

Kent is right. When I said “If waterfall is going to work, you need detailed specs,” I might as well have said, “If you’re going to jump to the moon from standing position, you’re going to need really strong legs.”

I don’t think waterfall works for most software development, and I don’t think it works for any game development.

But here’s the thing. If you’re working in what is basically a waterfall environment, you need those specs or there will be disaster. At the very least, QA is not going to have any idea what it is they need to test. This is because, in waterfall, QA is pretty much defined as “testing against specs.” (However, in a properly-managed non-waterfall project, this can be radically redefined.)