Waterfalls not considered harmful

With apologies to the late, great Edsger Dijkstra. Image from Wikimedia Commons.


Agile methodologies are all the rage these days, with good reason: they work better in the chaos which characterizes most software development shops.

The classic waterfall model of software development is pilloried as an example of how not to do things, but if you think about it, you'll realize that Agile's key insight is to do small iterations, each of them a waterfall.

Heh. Chew on that a bit, and let's discuss...

You still need requirements, although with Agile, you call them user stories or use cases.

You still need design, although now you can sometimes back into it by doing test-driven development. Sometimes, and only on a small scale. I'd argue that you still need the big picture to do design correctly, and the bigger the picture, the more design you need. Design is a topic for another post, so I'll stop here.

You still need to implement - write code, breathe life into the design, etc. - although with TDD, this is a fortunate side-effect of the process.

You still need to verify the code, but with unit testing frameworks, that's much easier. If you're doing TDD, well, you're already done!

Finally, you still need to maintain code, and this is one place where I think Agile gets it very wrong with their emphasis on face-to-face communication over documentation*, because maintenance without documentation is a nightmare. The Agile folks must write a bunch of throwaway systems... but I digress.

Anyway, I think the point of this post is that new things are often just a way of looking at or using an old thing differently.

* While I'd be the first to admit that technical people frequently send email when they should use the phone or just get up and walk over to someone to talk with them, one thing you have with written communication like email is a searchable record of what was discussed and what (if anything) was decided.