Joel turned me on to a Rands In Response posting titled "Incrementalists versus Completionists" where Rands relates a discussion with a co-worker where the co-worker found a problem, Rands suggested a temporary and incomplete solution that could be achieved in the time allowed. Rands was then stunned to find out his co-worker saw that as worse than doing nothing.
He breaks this down into those "dreamers" want to do the whole thing right or nothing (completionists) and "realists" (incrementalists) who are the good, smart guys who get things done.
Now I place myself in the incrementalist category, but not for the reasons that Rands suggests. Rather having been down the road of the archetypal completionist architect I have discovered the joy of getting stuff done in an incremental fashion toward my goal of the right thing. Because the thing I discovered was that my idea of what was the right thing kept changing as I learned new things. Both because of factors external and internal to the project. Interestingly Joel actually made me think about this for the first time in his article "Things you should never do, part I"
The reason any of this is interesting to me at this moment is the client I am working with wants to "do architecture" for several months as part of a application port from COBOL & Natural to J2EE. This stikes me as very completionist as conversations tend to be along the line "if we can just nail down the right architecture..." Another company I'm talking with wants to spend 4,500 hours developing the right architecture so they can port all their existing applications over to it.
My question in these situations is "where is the value"? Is there any value to changing the architecture when everything is already running acceptably? In the case of moving off the mainframe you might be able to make a case. But unless the end user is going to see some improvement in something they care about, I believe changing the architecture to be better is nonsense.