Mudança. Todos temem à mudanças. E não seria diferente ao codificar software, não é mesmo? Para que mudar se podemos continuar com nossa atual rotina simples e praticamente automática? Aquela coisa de chegar no trabalho, fazer o de sempre, como aprendeu no tutorial há tempos atrás ou que viu o ex-chefe fazer e até hoje executa assim sem questionamentos.

Em software isso recebeu um nome no livro The Pragmatic Programmer. Caso o cenário acima encaixe no seu code-style, você está programando por coincidência. Gosto do termo em português, pois ele é duplo sentido. Além de indicar o estado profissional acima, ele também implicitamente diz que você está na área por um mero acaso. * O livro não fala disso. Essa segunda parte é totalmente de minha autoria. Pode parecer xiita, mas te convido a refletir sobre isso mais a fundo.

Ao entrar no seu modo automático e passar a fazer coisas sem se questionar o porquê está fazendo (ou fazendo novamente) aquilo, você está programando por coincidência. Seguir aquele fluxo toda vez que depara com um problema passado sem questionar-se o motivo e se há melhor alternativa, você está programando por coincidência. Se, você assume coisas - isso vale muito pra teste - por exemplo que o erro X é causado pelo Y, simplesmente porque você acha que isto ocorre, você está programando por coincidência. Neste caso você não deveria assumir, mas sim provar que o problema é aquele mesmo.

Saindo da coincidência

Uma das formas de evitar esse ciclo de tédio e comodismo é justamente fazer Test-First. Explico os motivos:

1. Lego Effect: como comentei no Teste Unitário?, começar pelo teste fará você pensar em como aquela funcionabilidade que pretende fazer irá se relacionar. Isso te faz pensar mais e consequentemente, dúvidas virão e você buscará saná-las (livros, pesquisa na Internet, Twitter, outros devs, projetos Opensource).
2. Ah, a preguiça! Os testes te ajudarão a achar o menor caminho possível para aquela implementação. (teste é coisa de preguiçoso, lembra?) Isto te fará repensar técnicas. Com a prática de novas técnicas, você evoluirá como desenvolvedor.
3. Não mais dúvidas sem resposta! Com teste, você pode testar não apenas o código de implementação mas também as suas suposições. Pensamentos do tipo: será que isto pode funcionar desta forma? serão mais frequentes, uma vez que o espaço entre o será que... e a resposta são apenas escrever um assertion simples e executá-lo.
4. You on Rails. A prática do Test-first te mantém na linha de fazer o que realmente importa. Sem suposições vazias; Sem achismo; Você se antecipa dos problemas que poderá encontrar. Estar alinhado em fazer o que importa te torna introspectivo.
5. Test & fail. Test & Learn.
6. Não sendo mais telespectador. Você no controle! Não mais sendo guiado por processos e rotinas sem saber o motivo de estar fazendo aquilo daquela forma.

Questione-se; Reflita; Pense um pouco mais sobre sua forma de fazer as coisas. Isso é realmente a melhor forma de se obter o resultado que deseja?

Recentemente peguei meu Card Deck que ajudei a fundar (?) no Kickstater. Um dos cards que mais me chamou a atenção, até pelo fato de eu já ter feito isso anteriormente é o Remove your BEST idea.

Conseguiu achar uma solução para o problema? Ótimo! Ela poderá ser seu backup caso as coisas dê muito errado. Empenhe-se para achar uma outra melhor ideia. Vale muito a pena esse exercício.

Concluíndo

Test-first é uma das formas de acabar com a programação por coincidência. Test-first entretanto não irá te salvar de todo o mal do mundo - mas posso afirmar, por experiência própria que ele te coloca on track novamente.

A propósito, já leu o The Pragmatic Programmer: From Journeyman to Master? Permita-me dizer que você deveria se ainda não o fez pelo menos uma vez.