Após uma a boa discussão gerada pelo meu post sobre TDD + YAGNI achei interessante fundamentar ou corroborar minhas opiniões citando alguns especialistas no assunto.

Mas antes quero novamente deixar claro alguns pontos:

• Não acho que o TDD seja essencialmente ruim ou falho, somente quero pontuar alguns pontos que merecem atenção
• Acredito que existe muita gente aplicando TDD e sendo muito bem sucedido, porém com a disseminação das técnicas ágeis pessoas sem experiência irão adotar o TDD e podem cair em certas armadilhas e ter maus resultados

Minha preocupação sobre uma possível anorexia de design resultado de um processo TDD + YAGNI é compartilhado por Sam Gentile, defensor e praticante de XP desde seus primórdios.

My experience in the 90's with the XP community was that they were not the world's biggest fans of Architecture and most notably Software Architects. These topics realize perhaps a bias especially with topics like ArchitectsDontCode. At first glance, we got that right. … But it's not enough … Someone with Architecture experience needs to perform explicitly the role of Agile Architect and restore these capabilities to a team …The answer is NOT a BDUF Architect coming down from the mount with the stone tablets!! The answer is an Agile Architect.

Como ele diz a arquitetura do software era totalmente criada ao longo do processo de escrever o código-fonte. Na época era uma reação radical contra os processos muito pesados e os non-coders architects. No entanto hoje existe a necessidade de pensar em alguns pontos da arquitetura com certa antecedências, você tem que definir se vai usar web services ou remoting, qual framework de AJAX, ORM ou DAO, assim por diante.

Wendy Friedlander, desenvolvedora que trabalha em um ambiente hardcore xp, como ela própria define, conta sua experiência como TDD iniciante e seu conselho para quem deseja iniciar na prática.

Whenever I talk to someone who is interested in learning TDD I let them know that it is a very difficult concept to put into practice … Nobody mentioned this to me before I started. Everyone spoke of TDD like magic -- it changes your design, its the best thing ever, its so simple, all you need to do is write your tests before your class, you'll love it...

Apesar do final feliz e de ter, segundo ela, se viciado em TDD, o processo de aprendizagem levou uns 6 meses e muito estudo e adaptação.

Jeremy Miller outro grande defensor do TDD afirma no post New TDD Design Starter Kit Article is Online:

Personally, I still like to sketch out a skeleton design on paper or whiteboard before I jump into the unit testing.  More and more I've found myself using design techniques from Responsibility Driven Design as a quick way to break down a coding task into constituent parts just to find a place to get started. 

I obviously think TDD is very important, but sometimes it's just not enough by itself to create good designs.

Em seu post TDD Design Starter Kit: It’s All about Assigning Responsibilities Jeremy explica como é o seu processo de desgin utilizando Responsibility Driven Design + TDD.

David Starr, outro praticante de Scrum e técnicas ágeis pergunta:

Successful ESD [Evolutionary software design] does include (Big D) Design.  Some decisions are required up front.  This means we must make decisions such as Monorail vs. ASP or nHibernate vs. Datasets and many others.  Additionally, is it really a bad idea to predict logical extension points for your application and build in abstractions for them in v1.0?

Bom estas são algumas citações que de certo ponto corroboram minha preocupação com a anorexia de uma arquitetura criada aplicando TDD + YAGNI ao extremo. Na minha opinião bom senso ainda é o melhor conceito de todos, nunca abra mão dele.

OBS: Além de serem profissionais de ótima reputação, todos eles escrevem em inglês, que soa muito mais convincente que o meu português básico :)