Design is back. Long live design

It is very encouraging to read from the experiences of agile practitioners that they think up-front design (Architecture and framework) is too important to be left implicit in any methodology. I always believed in up-front design and evolutionary design facilitated by effective refactoring and automated testing, being core parts of any methodology. There are complimentary to each other, rather than forcing a programmer to use one over another. You dismiss one; you have a very lousy software at hand.

Martin Fowler also advocates nicely in making use of best of both worlds. It makes more sense now.
http://www.martinfowler.com/articles/designDead.html


http://codebetter.com/blogs/sam.gentile/archive/2006/09/06/Being-an-Agile-Architect.aspx

Being an Agile Architect
We found that a year down the road that there was still a lot missing. Too many "infrastructure" or "framework" things were blowing by in this delirious rush to crunch out 100% business functionality every week no matter what. Someone with Architecture experience needs to perform explicitly the role of Agile Architect and restore these capabilities to a team

http://codebetter.com/blogs/scott.bellware/archive/2006/09/19/149368.aspx

Sam's post on agile architecture has led to the death of my last vestiges of my denial in regards to a need for some formal recognition of software design on an agile team.

The absence of explicit software design activities on our team has lead to some degradation of software design that is leading the code down the slippery slope to opaqueness and to the initial indications of software entropy. We're trying to add a bit more formality to software design and software design guidance into our process. Recognizing a software designer's role on the team tasked with up-front design and continuous software design quality assurance is part of this effort.

Footnote:
It pays to be a coward Extreme Programmer