Software Development and Religion

If anyone thinks they can eliminate religion just have them spend time around software developers. Even if you can get them past the "Great Windows Vs. Linux" debate you're bound to run into other topics of controversy and dogma. Which development methodology to use is one such topic.

I'm going to be a presenter at a local development conference this month, and I've been digging in to various methodologies to make sure my remarks are broad enough to apply to as many situations as possible. Today is "Agile Day".

To be honest, I'm going to have to plead agnostic. After spending several hours on the finer points of Agile, I can honestly say: It doesn't matter which methodology you choose. Any methodology, if you do it well, will deliver a quality project. No methodology, if you do it poorly, will save your bacon.

The main advantage of Agile is that it tosses out a lot of extraneous steps and processes. The main weakness of Agile is that it tosses out a lot of "extraneous" steps and processes that might not be extraneous. Unless I've missed something along the line, it relies on gut instinct more than other methodologies, and hence relies on experienced developers to get the job done. Unfortunately, that doesn't speak well for the methodology. Any methodology will work if you use only experienced developers.

I see Agile as being the preferred methodology for consulting teams and implementation teams. It has the potential for abuse by these groups, as well. With such minimal up-front planning, it would be very easy to put the project into continuous loop, thus prolonging the engagement and running up the bill.

On the other hand, if it's done right I can see it as being very effective. I just suspect that "getting it right" is more difficult than people appreciate. Inexperienced project teams just will not get it right, period. The only saving grace is that the methodology makes it easier to disguise that you're not getting it right.

What really amuses me are the various advocates who try to play "peacemaker" among the methodologies. These are the people who say "Well, you would use this methodology in these cases, and this methodology in these cases here." It sounds good in theory, and in theory it is correct. There are some methodologies that lend themselves better to certain types of projects.

The problem is that very few organizations possess the skills, size, and discipline to pull it off. Most organizations are struggling to execute one methodology well. Add another methodology two and you'll have the software equivalent of "I speak three languages, each one badly". More often than not everyone will just be confused. It is better, I think, to learn to execute one methodology well, even if it's not always a good match for the project, than to execute with mediocrity in several.

Anyway, it's been interesting research so far. Agile is especially hard on my particular area of expertise: documentation. In short, they're against it. Or at least that's how it comes across. If you dig deeper they're really just attempting to reduce the overhead that often creeps into documentation efforts in one-size-fits-all methodologies. They're not saying "don't document," they're saying "document only what makes sense". And I will admit that far too often some documentation doesn't make sense.

In any case, I'm glad I'm giving this presentation. It's helped me to look outside the rut I've been in with my current job and see what other things have been going on in the industry. My presentation will be much better for it. And it will help immensely in preparing for any religious fanatics in the audience.