No final do podcast o Vitor comenta sobre o artigo que diz que o programador é mais produtivo quando está corrigindo um bug do que quando está implementando uma feature nova.
O que eu pude enteder disso é que quando você está trabalhando em um bug, você tem um ponto final. Você sabe exatamente quando parar de codificar, que é quando o bug sumir. Ao implementar uma feature nova sem TDD, quando você acaba? Quando estourar o prazo? Quando você achar que não tem mais nada para codificar? Quando você testou a feature 10x seguidas e não deu nenhum erro?
Ao fazer uma feature usando TDD, você sabe exatamente quando parar, que é quando não há mais testes para escrever.
Foi isso que eu entendi do comentário.

Gostei também do comentário que fizeram do TDD no Ruby. Ainda não tinha caido a ficha aqui de que no Ruby, sem TDD, seu código fica muito mais vulnerável a erros.

De resto, parabéns, ficou muito bom.

Respondendo a algumas perguntas:

Alexsandro: Uma companhia interessante seria outro desenvolvedor, um que saiba aplicar o TDD, para ajudar. O analista de testes também pode ajudar, mas caso ele não saiba programar, pode ficar um pouco complicado, pois a idéia do TDD na verdade, é fazer o desenvolvedor pensar na solução antes de desenvolver, onde ele pode encontrar problemas de especificação. O analista de testes vai estar focado em modelar casos de teste para achar defeitos, então foge um pouco do assunto.

Leonardo: Acredito que valha sim. Claro que com uma documentação de qualidade, fica mais fácil aplicar o TDD. Creio que quanto mais os desenvolvedores saibam TDD, mais fácil ficará de resolver este problema, pois vai ter alguém para auxiliar. É como ter um programador júnior que tem problemas em utilizar o padrão Singleton. Acredito que boa parte dos colegas de trabalho poderão ajudá-lo.

Tenho feito estudos com o TDD sendo aplicado no desenvolvimento de um SAD, e os resultados estão sendo ótimos, pois os problemas são encontrados na especificação, reduzindo o custo das mudanças ($$$) e removendo defeitos.

Se for, como fica nos casos em que o desenvolvedor acabou de chegar na equipe, e ainda não conhece o sistema como um todo, e a documentação do mesmo não é das melhores, ou não é suficiente.

Vale a pena para o profissional, no caso o desenvolvedor, aprender o TDD de verdade?