Agile may just be for some

I was reading an article about Agile programming the other day when a thought struck me. When I first look at a programming problem, even if it's a significant effort that will take a team 6 - 12 months of effort, I get a picture in my head of the basic design pretty quickly.

And that basic design tends to match the final product. It may match because I keep pushing in the direction of what is in my head or it may be that I just come up with the "best" approach - but the final product does match.

So when the agile approach says to just design for the module you are working on - basically I can't. I design that module in the context of a complete architecture. And this is a good thing - designing each piece in the context of the full architecture.

But this raises an interesting question. I think most programmers cannot picture the entire architecture up front. But a minority of them can. What if the proponents of agile programming tend to be in this minority that can picture the entire architecture in their head - and the architecture they picture is correct. (Read the book Blink for more on this.)

Agile is a great method for programmers that can do this. But at the same time, it arguably is a terrible approach for programmers who do not have this ability. It seems to me that maybe we should look at who should use agile methodologies and who should not.

Comments

[Kalani]

I've been interviewing at various places in the NYC area. My experience has been that the companies focused on contracting have emphasized "agile processes," while regular software companies have focused on "big up-front design." I think that the underlying business model has a lot to do with this.