On Agile...

You've heard said it before: in order to learn one must have an open mind.

I think sometimes the opposite is better. Keep a closed mind. Let the new idea try to make its way in with difficulty. Let it argue itself in with facts. Let it convince you of its correctness. Once convinced, make it your own. If the idea has enough merit, it can make its way in.

I've been trying to like the Agile methods, but for reasons I still cannot pin down, I am still pessimistic about these approaches. There is no doubt they work. Sometimes. But that's not a criticism. Nothing works everywhere. Agile's more moderate proponents have never suggested that is applicable everywhere.

I should clarify that I am pessimistic mainly about the XP approach, since that is the methodology I am most familiar with among the agile methodologies. I am still agnostic about the rest.

These methodologies have been developed because of the unworkability of the one-pass waterfall approach. In an ideal world, where people do not make mistakes, the one-pass waterfall is the simplest and most efficient approach to developing software: complete the requirements in one phase, then complete the design, then complete the programming, then complete the testing, and finally, complete the acceptance, and we're done.

But since we're not mistake-proof, the waterfall is simply impossible as an approach, and no one in their right mind will attempt to develop software using this model. Except in the business world, of course.

Here's one of my issues. No one has been complaining that the programming phase of a waterfall approach comes out with a program that does not match the design documents. No one has been complaining that the design documents do not match the specified requirements. In other words, the problem is not with the design phase and it is not with the programming phase. The problem is, and always have been, that the specified requirements do not match the actual requirements.

If that is true, then it is the domain of requirements analysis that is at fault. They come up with the faulty requirements. The domain of software design and programming is just fine -- give us the correct requirements and we'll give you the correct software.

An approach that tries to fix the system development problem by fixing the software design and development phases rather than the requirements phase is looking under the wrong lamppost. And I think Agile is doing just that.

Be that as it may, I'm currently reading Robert Martin's Agile Software Development and have more to say on the topic.