Religion Doesn't Belong in Software Development

Apparently there is a religious war going on between two factions of software developers. You have your big-design-up-front folks, and your agile folks, and if what I'm seeing in the blogosphere is any indication, they are engaged in a bitter war for religious superiority. I'm going to tell you why they're both wrong.

I cannot stand developers who get religion, especially when it's about stupid things like how to format the code (answer: pick something that everybody can live with and move on; no, your particular way isn't better than anybody else's way), how much to document the code (answer: as much as necessary, which is not as much as you think, but no more), or any of the other things we developers fight about instead of actually building the software. Religion about the development process is pretty stupid, too.

Greg's first rule of development process: if your process has a name by which it is recognized far and wide, your development organization has religion.

That's right. Agile, Scrum, XP, Waterfall, Rational, Test-First; all of those are religion, and I'm sure there are many others, as well. If you ever interview at a place and they say "We do Scrum here" or "We are an Agile shop", etc, run away, because the development group has got religion and you don't want that.

Why is religion bad? Well, by its very nature, it is rigid and inflexible, and represents in the mindsets of its practitioners the idea that they don't have to think about this stuff any more, the process takes care of it all.

Except, it doesn't, and you have to think about this stuff, constantly. The main problem is, no matter how much some developers want it to be so, one process does not fit all. For instance, if you are starting from scratch, good luck getting to your first version in any kind of useful time frame with no design up front. In that situation, you have to develop a foundation for the software, and doing it the Agile way is just not helpful because you must have some agreement at some level of what the hell you're doing before you can start doing it.

If are past that, and are evolving an existing product, then the approach you should take depends on, well, a lot of things, and there's no way any intelligent developer would say "Let's do XP" or "We need this big specification phase first" without knowing all of those things, which should be evidence that perhaps you can't use the same process for all projects.

Greg's second rule of development process: Do what works for your project right now.

I have seen various processes come and go (and come back with new names) over the years, and if I've learned anything, it's that there's really nothing new under the sun. Every so often, somebody comes up with the One True Way that nobody could ever have thought of before, and they give it a name, and suddenly it's the hot new thing. Except it's not hot, it's not new, and it can't be the One True Way. So, instead of searching for the One True Way, I've been searching for the ways that work, and the answer is: It depends.

The bottom line is, have smart and experienced developers in charge of the process, don't subscribe to one religion, and Do What Works. Sometimes that's doing a big design up front and sometimes it's doing iterative refinement in small chunks. Most of all, don't decide that what you've been doing works so well that you give it a name and write a book about it. That way lies madness.