Mi sporgo piu' verso la parte di Jim, Robert in mia opinione ha bevuto un po' troppo il kool-aid del TDD. Come ogni strumento in software, conoscere TDD e usarlo nella maniera opportuna al momento opportuno e' una delle qualita' che differenzia un buon ingegnere dalle masse, ma andare a dire che non si puo' essere un professionista se non si usa TDD... dipende dalla situazione, dipende dal progetto, dipende con chi stai lavorando.

Anche io sono più in linea con Coplien. Trovo difficile riuscire a praticare il TDD in maniera così spinta (e così vincolante). E sicuramente non credo che non usarla mini la professionalità di uno sviluppatore. Ma credo che il TDD debba diventare più comune, diffuso e soprattutto richiesto da clienti e aziende. Spesso non si da sufficiente peso a questa tecnica perchè "non c'è tempo" o "costa troppo", per lo meno in italia. Poi è chiaro che quando ci si attacca a determinate metodologie in maniera religiosa ed estrimista è difficile evangelizzare determinate tecniche.Diciamo che posso capire il non voler far emergere tutta l'architettura dai test, ma preferire una parte di up-front-desing con magari i contracts, ma dopo qualche tempo che mi ci sono abituato trovo fondamentale riuscire a fare per lo meno il maggior numero di unit ed integration tests il prima possibile; magari nel mentre avendo un pò di prod code anche già scritto, senza seguire in maniera rigorosa sempre il red-green-refactor. L'importante è ridurre al minimo il time-to-execute, eseguendo pezzetti di codice isolati il prima possibile verificandone la funzionalità, senza avere un intero sistema funzionante o senza doverlo necessariamente tirare su tutto, e questo è il punto dove poi infatti Martin e Coplien hanno avuto la convergenza.

E concordo sul valore di design by contract in contrasto al TDD, combinato con peer reviews.

Magari i politici facessero dibattiti come gli ingegneri...