In the course I teach for senior testers, we spend a few hours talking about different approaches to software development (waterfall, agile, v, w, rup, etc.). At the end of the discussion I, of course, tell them which approach is best.
Of course, I'm kidding - I hope anyone reading this realizes that. There are better ways to make software, and the hard part is figuring out which approach is best for the given situation and personnel. Steve Yegge posted a follow up to his "Good Agile Bad Agile" post this weekend. Like all of his posts, it's long, but well written with good points. If you have been under a rock and haven't read his agile post it's a good read whether you are a fan of agile or not.
Let me preface my rant by stating that I like Agile. An Agile approach may not be the best solution for every software problem, but many of the approaches that live under the agile umbrella are make a lot of sense for creating good software. One thing that bugs me (and it may just be what I've seen) about the devout agilists is the notion that non-agile approach to software development is inherently waterfall based. This is like saying any condiment that isn't mayonnaise must be ketchup. Ok - maybe not exactly like that, but I'm writing in a hurry :}
Waterfall (and it's brother and sister v-model and w-model) have been used to ship a lot of software. And...I guess that's about the only good thing I have to say about it right now. The idea of entirely completing any phase before starting on the next phase is ok in theory, but rarely works in practice. This is especially problematic in just about any project longer than six months or so (completely made up number - I don't have any empirical evidence to support that figure - it just seems accurate to me). Most projects I've worked on have been closer to spiral model (break a large project into milestones and take time to review the process and progress at each checkpoint) than anything else. Sometimes, it has worked, and sometimes it hasn't. Usually the teams I have been on have learned from their mistakes, and sometimes they haven't. I think those observations could be said of waterfall or agile (or even rup) projects as well.
Now let's discuss the Noodle Madly** model of software development. In the NM model, you look at the scope of the project, the people assigned to the project (including their experiences), and the goals of the project and design the engineering model with those things in mind. For a small internal project, a model based on Agile methodologies may be adopted. For a larger project with hundreds of people working on it you may choose something closer to spiral - or - you may choose a hybrid model. For example, because you have a 7 year support plan in place, you may be locked into creating complete design and functional specifications. However, you see short iterations as beneficial, so you choose to have milestones end every 6 weeks. You find that the engineering team is reluctant to have a team room, so you keep people in their individual offices - but you get every sub team to agree to work in a team room for one week every milestone. You may or may not decide that pair programming or pair testing will be part of the plan - it depends on the team and the work they need to do. That's the beauty of the NM model of software development. It's not based on blind faith that the plan will work for everyone - it's a plan created by people who understand the system and the components that make it up. It's a model that allows for reflection and compromise, and a model that can be used to create great software no matter what the audience is.
But what do I know?
** anagram of 'any old model'
[ed. 3:15pm - Yes - I realize that in theory, agile promotes individuals and interaction over process, but that's not what I see agilists practice. I see individuals and interaction over process and tools as long as the processes are purely agile based. ymmv]