Resista à tentação de criar seu próprio monstro.

Há algum tempo falei aqui sobre a sindrome do arquiteto astronauta, e retomo o tema hoje.

Caso você seja um arquiteto de software, ou tenha tendências a se tornar um, provavelmente está nesse momento implementando ou criando em sua mente algum SeiLaOQueFX, aquele framework que irá satisfazer a tara que todos nós temos por reuso, coesão, simplicidade. Simplicidade? Sim, ao menos é o que normalmente pensamos.

Com o SeiLaOQueFX você e os demais programadores da sua equipe não terão mais dificuldade em implementar um processo de negócio qualquer, poderão se abstrair dos requisitos não-funcionais e focar apenas no que interessa ao negócio. A produtividade da equipe será foda, ninguém mais precisará repetir código, reimplementar padrões, ter que conhecer tais padrões, pra começo de conversa.

Claro que o fato de todo mundo agora ter que conhecer o SeiLaOQueFX mais que qualquer coisa que já estudou ou usou na vida é um mero detalhe, e você está ali para resolver qualquer problema. O fato de você reescrever todas as rodas e engrenagens possíveis também é só outro detalhe. É necessário, afinal o que tem por ai para ser reutilizado é genérico demais e não é bom o suficiente para satisfazer nossa tara por reuso.

Mas aqui vai o que lhe espera, e não negue esta verdade, será pior pra você: Riscos, risco em toda parte. E alguém pagará a conta; se não for você, será sua equipe, ou seu empregador. Sua satisfação inicial em criar o tão sonhado SeiLaOQueFX dará lugar a um sentimento de frustração, de impotência, afinal o fracasso não será culpa sua. E neste ponto não estou sendo apenas irônico. Provavelmente não será mesmo. Mas contará com a sua conivência em todo caso.
Mas o que fazer para não cair nessa armadilha, e não ser um eterno frustrado por nunca ter dado vida ao SeiLaOQueFX?

Uma primeira alternativa é fazer isso fora do trabalho. Se é tão importante pra você, você encontrará tempo. Isso evita que você comprometa seu emprego, sua equipe e seu empregador com os vários riscos que um framework escrito do zero traz.
"Mas sem o SeiLaOQueFX meu trabalho será tedioso, repetitivo, ineficiente". Provavelmente, pois é justamente isso que nos leva a querer ser pai de uma criatura como esta. Mas há outra motivação, interna e quase sempre negada, para fazermos isso. A preguiça. Isso mesmo, preguiça. Palavra forte, mas é o que acontece. Desenvolver nosso próprio EntityFramework, nosso próprio ASP.NET MVC, nosso próprio WCF é sempre mais motivador que aprender a usar estes aí.

Mas é aí que os riscos entram em cena. Todos sabemos que nunca temos à nossa disposição o prazo que precisamos para fazer o trabalho como queremos. Além disso, nosso empregador está pouco se lixando para o SeiLaOQueFX; o que interessa pra ele, e ele está certo em pensar assim, é o produto que ele está lhe pagando para entregar aos clientes dele. Com um framework desenvolvido do zero, inúmeros problemas inerentes ao framework, e não ao software que o utiliza, precisarão ser resolvidos, e quando estes problemas surgirem, não adianta ir tentar explicar ao seu empregador que o SeiLaOQueFX é foda e precisa de mais tempo. Você não está sendo pago para desenvolver frameworks, está sendo pago para desenvolver produtos de software e o desenvolvimento do SeiLaOQueFX está por sua conta e risco. Resultado: Gambiarras. Gambiarras em toda parte. Como você não tem tempo para aplicar o seu brilhantismo e resolver os problemas do seu framework com dignidade, você o fará sem dignidade mesmo, e a culpa é do seu empregador, que não lhe deu tempo pra isso. Portanto, ele que se ferre com a perda de qualidade.

Nesse momento sua equipe estará entrando em colapso. Muitos não irão mais querer usar aquilo que você diz que eles tem que usar e alguns pularão do barco até; outros seguirão paralisados, com uma produtividade cada vez mais baixa. Por fim, tudo aquilo que você sonhou como produto do SeiLaOQueFX se manifestará com sinal invertido, e em um nada belo dia você brigará com todos, discutirá com seu empregador e seguirá seu rumo; irá para algum lugar onde seu brilhantismo seja reconhecido. E ai, ai ferrou pra quem herdou a criança. Sua reputação estará manchada e no fundo você saberá que enfiou os pés pelas mãos, embora dificilmente admita.

Portanto, resista à tentação de criar seu próprio monstro.

TDD está morto?

Nesta semana o chão estremeceu após a declaração de David Heinemeier Hansson (@DHH), autor de livros como Getting Real, Rework, Remote, além do framework Ruby On Rails e do Basecamp, postada recentemente em seu blog, de que para ele TDD está morto. O texto original pode ser encontrado aqui.

Nos últimos anos quem busca estar sempre atualizado com as práticas modernas de desenvolvimento de software tem ouvido sempre que praticar TDD, ou seja, escrever testes unitários antes de escrever o código que será testado, deve ser uma prática obrigatória para se garantir a qualidade do trabalho realizado. Livros e livros foram escritos sobre o assunto, e provavelmente alguns mais ainda serão.

O desenvolvimento utilizando TDD é conceitualmente simples: Para cada método público que pretende escrever em cada uma das entidades que compõem seu software, escreva antes um ou mais testes unitários que entreguem a esse método algumas combinações de parâmetros de entrada, o executem e por fim verifiquem se o resultado de sua execução é aquele esperado para cada um dos conjuntos de parâmetros informados. Faça isso escrevendo primeiro os testes, em seguida, antes mesmo de escrever o conteúdo do método a ser testado, execute os testes para garantir que eles não estão indicando um falso positivo, em seguida escreva apenas o mínimo de código necessário para fazer com que aquele teste passe e por fim refatore o código para torna-lo mais claro e/ou eficiente. Ao terminar essa refatoração seus testes passaram novamente e você terá um indicador para lhe dizer caso alguém faça uma besteira e acabe alterando o comportamento do seu método.

Tudo muito lindo, até se colocar em prática. Na prática, é muito difícil determinar o que testar, além de a arquitetura e o desenho do software mudarem bastante à medida em que sua implementação evolui. E quanto mais granulares os seus testes, mais difícil será mantê-los atualizados. Sem falar no inferno de mocks, fakes e stubs que acabam sendo necessários para permitir que apenas aquele método, aquela unidade de código, esteja de fato sendo testada naquele momento, e não tudo que é executado como dependência a partir dela.

Diante dessas dificuldades, muitos desistem do TDD. Creio que a maioria desista, por elas e pela falta de disposição em aprender e treinar o calhamaço de novas habilidades necessárias para se praticar TDD. Em Janeiro de 2012 o maior advogado do TDD, Uncle Bob (@unclebobmartin), autor de livros como PPP, Clean Code e The Clean Coder, escreveu um artigo em que falava justamente sobre a mudança de posicionamento necessária ao desenvolvedor para que ele pudesse finalmente virar o bit e se tornar um praticante de TDD. Esse artigo pode ser visto aqui, e é um interessante contraponto ao que foi apresentado ontem pelo David.

Pelo que já coloquei acima, já da pra perceber que minha posição se assemelha mais à posição do David nesse caso. Sempre fui extremamente pragmático, e escrever quilos e quilos de mocks e testes para verificar o comportamento de um método que em poucos dias provavelmente nem existirá mais nunca ganhou minha simpatia. Estudei muito a respeito, ainda tenho livros na minha estante sobre o assunto que lerei em breve, mas nunca consegui assumir essa prática (TDD) como uma religião, como muitos tem feito e advogado que deve ser feito. No entanto, assim como David, não me coloco no outro extremo, não sou de modo algum um Programmer Motherfucker que quer apenas escrever código do jeito que bem entender, sem critério algum por que é isso que fazermos, programar. Não estaria me dedicando a este blog agora se fosse esse o caso.

A saída pra mim foi encontrada na verdade em um irmão mais novo do TDD (Test-Driven Development) o BDD (Behavior-Driven Development). Ao qual tenho me referido bastante ultimamente como Especificação por Exemplo.

Após Dan North (@tastapod) introduzir a técnica denominada BDD, muitos afirmaram que BDD não seria mais que TDD feito da forma correta, e a forma correta nesse caso seria dar ênfase ao comportamento a ser apresentado pelo software a ser testado, e não a um único método, uma única unidade de código. Neste link e neste link vemos respostas de Uncle Bob a esse tipo de afirmação.

Dando ênfase a um comportamento, favorecemos a modularização, damos um norte ao desenvolvedor, que pode ter liberdade para criar o desenho do software, tendo como parâmetro o comportamento descrito. Tal comportamento pode ser definido por ele mesmo, ou em conjunto com outros envolvidos, como testadores e analistas de requisitos, mas será no fim parte do código fonte do sistema, será compilado, traduzido para código e testado, num ciclo muito semelhante ao ciclo do TDD, no entanto sem a ênfase absurda à unidade. Serão testes maiores, mais lentos, integrados, embora não necessariamente end-to-end. É uma técnica que com certeza vale a pena conhecer. Obtém-se muitas das vantagens do TDD, sem trazer consigo a maioria de seus problemas.

Enfim, não vou me estender demais. Queria apenas aproveitar a polêmica do momento e escrever esse texto contrastando as duas técnicas e expondo minha posição a respeito do uso de TDD.

Recentemente fiz um trabalho acadêmico sobre o assunto: Melhorando a Eficiência no Desenvolvimento de Software através da Aplicação de Técnicas de Especificação por Exemplo. Tal trabalho pode ser encontrado aqui.

Módulos de Negócio vs Módulos de Infraestrutura

Módulos de Negócio versus Módulos de Infraestrutura. Essa é uma das discussões que me deixam mais empolgados quando o assunto é Arquitetura de Software. Mas antes de mais nada, uma breve revisão sobre o que são Módulos.

Um Módulo de Software pode ser visto como uma peça de software que implementa uma determinada especificação e realiza um determinado trabalho conforme especificado. Tais módulos podem ser compostos por um arquivo, uma classe, uma DLL, ou até mesmo um conjunto de DLLs, dentre outras possibilidades, desde que em conjunto esses artefatos implementem uma dada especificação e realizem um determinado trabalho conforme especificado.

Sempre que falamos em Módulos de Software, é comum alguém fazer a comparação com Módulos de Hardware, e gosto bastante dessa comparação. Um módulo de hardware, um componente eletrônico normalmente, pode ser facilmente substituído por um outro semelhante, desde que este outro implemente as mesmas especificações. Os demais módulos que interagem com aquele que for substituído se quer perceberão a mudança. E este seria o Santo Graal da modularização de software, poder simplesmente remover um módulo e substituí-lo por outro que implemente a mesma especificação, sem que os demais módulos reclamem da mudança.

Infelizmente isso ainda é uma realidade pouco comum. Arrisco dizer que a grande maioria das aplicações desenvolvidas no país, ainda que considerando apenas a pequena amostra a que tive acesso, são mal modularizadas e acabam mantendo um alto acoplamento entre seus módulos. E isso prejudica não apenas a possibilidade de fazer substituições de uma implementação por outra, algo que apesar de muito bonito não é tão necessário assim, mas também a definição das fronteiras do escopo de cada módulo, e é ai que está o grande prejuizo em modularizar mal uma aplicação.

De volta ao tema desta postagem, vamos supor que estamos trabalhando no desenvolvimento de um sistema em que há uma boa modularização, em que o papel de cada módulo está bem definido, o acoplamento está baixo e as fronteiras entre os módulos muito bem definidas.

Se tivermos essa realidade, será fácil identificar a separação entre Módulos de Negócio, aqueles que implementam exclusivamente funcionalidades específicas do negócio que está sendo automatizado pelo software, e Módulos de Infraestrutura, que implementam funcionalidades de suporte, drivers de acesso a bancos de dados ou sistemas de mensageria, ferramentas de log e auditoria, gerenciamento de usuários e tantas outras que estarão presentes, sem muita variação, em praticamente toda aplicação que viermos a desenvolver.

Módulos de Infraestrutura são componentes genéricos, reutilizáveis, que podem ter seu desenvolvimento e manutenção totalmente desacoplado dos sistemas que os utilizam. E ai está a grande vantagem em sermos capazes de fazer essa distinção. Quando baixamos um módulo como o Json.NET ou o FluentAssertions através do NuGet, recebemos uma peça de software pronta que apenas consumiremos. Por que não pode ser assim com os Módulos de Infraestrutura desenvolvidos pela própria equipe que consome esses módulos desenvolvidos por terceiros?

Pense que há na empresa em que você trabalha, e não há porque não haver caso você desenvolva aplicações .NET, um repositório NuGet privado, assim como uma política de Gestão de Reuso que defina que todo Módulo de Infraestrutura deva ser desenvolvido de modo independente das aplicações que os consomem, e que devam ser disponibilizados neste repositório uma vez que atinjam uma versão estável. Isso permitirá que esses módulos sejam utilizados pelas equipes de desenvolvimento da empresa, incluíndo as equipes que os desenvolveram, pois estas também deverão consumí-lo através do repositório NuGet, e não através de referências diretas a projetos da mesma solução.

Num cenário como este, teriamos uma solução limpa, composta apenas por Módulos de Negócio se referenciando entre si e consumindo, via NuGet, os Módulos de Infraestrutura que precisam.

Pensem nas possibilidades que um cenário como esse lhe proporcionaria. Pense em possibilidades como abrir alguns desses módulos como projetos Open Source, ganhando a contribuição de desenvolvedores de todo o mundo. Ou a vantagem de poder vender a seus clientes apenas o que realmente precisa e deve ser entregue exclusivamente a esses clientes: seus Módulos de Negócio. Afinal, se você pode consumir componentes de terceiros não relacionados ao negócio do seu cliente sem ter que fornecer a ele a propriedade sobre o código desses componentes, por que não poderia fazer o mesmo com o código dos Módulos de Infraestrutura que você mesmo desenvolve?

Por hoje era isso! Deixem suas opiniões nos comentários.

"Apagão de talentos na área de TI? Que absurdo."

"Apagão de talentos na área de TI? Que absurdo."

Essa é a reação padrão de muitos profissionais de TI quando alguém diz que há um apagão de talentos na área de TI. Muitos verdadeiros talentos acreditam não estarem isolados, embora creio que a maioria se sinta assim. Já outros, talentos fajutos, que por alguma razão se consideram talentos natos mas que mal conseguiriam elaborar uma boa redação, se ofendem e partem pro ataque.

Não tenho em mãos dados estatísticos ou qualquer outra evidência forte de que esse apagão de fato exista, no entanto posso falar pela minha percepção. Já faz uns 8 anos que sou um dos responsáveis pela seleção de desenvolvedores e testadores de software nas empresas em que trabalhei nesse período, e o que observo é assustador. Sempre fui muito exigente e os exames de seleção que costumo aplicar refletem isso, no entanto sou criterioso o bastante para não exagerar e a impressão que fica é que a cada 10 que se candidatam, apenas 1 ou 2 merecem se quer serem considerados.

O mercado de TI nos últimos anos, em especial na área de desenvolvimento de software, tem se inflado cada vez mais de "profissionais" acomodados, que aprendem a fazer o básico, muitas vezes usando uma única tecnologia, uma única linguagem, um único framework, e mesmo assim escrevendo códigos de péssima qualidade mas que por já terem feito CRUDs por alguns poucos anos se consideram profissionais experientes. Há muitos profissionais de desenvolvimento de software no mercado, alguns são realmente bons e me daria orgulho os terem como colegas de trabalho, no entanto o que percebo é que são minoria (minoria no mercado como um todo, pois se considerar apenas os que participam ativamente das comunidades online de desenvolvedores creio que o número cresça bastante, pois apenas por estarem participando delas já podem ser considerados mais interessados pela profissão que os demais).

Portanto, o que penso é que há sim um apagão de talentos na área de TI, embora haja um excesso de profissionais disponíveis no mercado. E as más condições de trabalho e baixos salários pagos em alguns segmentos do setor em algumas cidades do país não servem como desculpa para o desapego e a falta de compromisso com a carreira que muitos demonstram. Pelo contrário, a baixa valorização pode até ser em parte justificada pelo excesso de maus profissionais, que aceitam qualquer condição de trabalho, desde que não exijam muito em troca.

Enfim, se quer saber o que eu espero de um profissional, veja este link e este link.

Uma retrospectiva pessoal dos últimos 3 anos!

O ano de 2013 foi um ano realmente produtivo pra mim. Concluí projetos pendentes, iniciei novos projetos, atingi objetivos profissionais, encarei novos desafios, e isso tudo é devido fortemente de uma mudança de atitude que ocorreu ao final de 2011.

Há algum tempo recebi um conselho que considero o mais importante que já recebi: "não invista demais em sua mente se esquecendo de cuidar também do seu corpo, pois um não vive sem o outro". Na época eu passava por alguns problemas de saúde devido basicamente ao estresse e ao sedentarismo, e esse conselho me fez abrir os olhos e perceber que de fato eu estava investindo demais em qualificação e deixando de lado o lazer, a saúde e o bem estar, algo considerado normal nos dias de hoje. Isso foi em meados de 2009, e de lá pra cá passei a dar muito mais atenção ao meu bem estar e principalmente à minha saúde.

Decidi, a partir de então, estudar menos, deixar as coisas evoluírem mais devagar, usar um pouco o produto de tanto investimento antes de investir mais. No entanto, isso me fez perceber que a qualidade do investimento que eu havia feito até então não era bem o que eu esperava. Ainda me sentia despreparado, ainda havia dúvidas que eu precisava responder para me sentir maduro profissionalmente.

Como então equilibrar as coisas? Voltar a estudar, produzir mais e melhor, e ao mesmo tempo não passar pelo estresse absurdo em que vivia?

Primeiramente, mudei de emprego, pois vinha de lá a grande fonte de estresse pelo qual eu passava. Mais que isso, pedi demissão sem nem mesmo ter outro emprego. Decidi ter férias prolongadas, esquecer completamente os compromissos e as consequências, passei dois meses apenas descansado, e por fim retomei os estudos.

Fiz uma breve pesquisa de mercado para entender o que eu precisaria aprender de novo, em que eu precisaria me reciclar, escolhi alguns livros, e passei a me dedicar a eles. Isso aconteceu em meados de 2011.

Era hora de voltar à realidade. Pesquisei um pouco a respeito de algumas empresas de Belo Horizonte onde eu gostaria de trabalhar e fiz contato. Destas, nenhuma oportunidade surgiu, ao menos não nas semanas iniciais, mas para minha surpresa recebi uma ligação de uma outra empresa, até então desconhecida por mim, que havia recebido uma indicação de alguém para me contactar, pois eu seria a pessoa certa para resolver o problema pelo qual eles passavam naquele momento. Fiz contato numa quinta feira, e no dia seguinte já havia sido contratado. Parecia mesmo urgente o problema rs.

Em um novo ambiente, livre do estresse de antes, encontrei espaço para buscar os novos desafios que precisava para me manter motivado.

Em paralelo a isso, passei a investir mais em saúde, o sedentarismo crônico ficou para trás, embora sempre passe de vez em quando para dar um oi. E a ideia de pesquisar o que eu previsava aprender, em que eu precisava investir, foi um ótima ideia. Aprendi muito com os 6 primeiros livros que escolhi, e vi que esse seria um ótimo caminho, muito mais produtivo que a participação em cursos e a leitura de blogs e mais blogs, os quais eram minha principal fonte de informação até então.

Apenas no segundo semestre de 2011 li 6 livros, um recorde para quem era acostumando a ler não mais que 1 ou 2 livros por ano, se muito. Em 2012 a produção já foi mais baixa em números, mas não em valor. Ao final do mesmo ano, diante do desafio de produzir um trabalho de conclusão de curso que demandaria bastante pesquisa, decidi tornar a leitura uma atividade mais frequente, e decidi que faria isso sem prejudicar as demais atividades do meu dia a dia. Qual a solução? Não mais que míseros 30 minutos de leitura diária, antes de dormir, principalmente. Com essa estratégia, consegui concluir, supreendentemente, 15 livros técnicos no ano de 2013. Isso enquanto fazia um curso de pós graduação, que me exigia em média 1 hora por dia de dedicação.

Hoje tenho tempo para me dedicar ao meu bem estar, e em 2014 talvez invista menos em qualificação, mas certamente com muito mais qualidade que nos anos anteriores a 2011. Ao que tudo indica, será um bom ano.

A sindrome do arquiteto astronauta

Desde que iniciei minhas aventuras com programação, na época que não fazia mais que encontrar novos meios de se usar a função SE no Excel 5, sempre gostei de pensar, inventar, descobrir e usar coisas novas. Cada novidade que eu podia experimentar, que podia tornar o código que eu escrevia mais agradável, me trazia satisfação. Não me bastava saber como criar uma tela de cadastro, isso já no Delphi, eu queria sempre buscar uma nova maneira, mais eficiente, de fazer isso, e ainda hoje tenho esse impeto pela inovação e pela maior eficiência. Arquitetura de Software sempre foi a minha praia dentre as várias que um desenvolvedor de software pode escolher. E claro, quem experimenta coisas novas erra muito mais que acerta. É necessário muita experimentação até se conseguir maturidade para identificar as chances de sucesso do próximo experimento, portanto coleciono muitas decisões equivocadas, das quais me orgulho pois cada uma delas contribuiu para os acertos seguintes.

Em meados de 2008, num período em que eu já me considerava capaz de criar soluções mais elaboradas, e já estudava com mais profundidade temas como padrões de projeto e boas práticas de desenvolvimento, me lembro estar construindo uma solução que, obviamente, tendia à perfeição. No entanto cada uma das imperfeições ainda existentes me incomoda absurdamente e cada dia eu gastava mais tempo tentando me livrar delas. Foi nesse período que alguém me disse: "você está sofrendo da síndrome do arquiteto astronauta, não deixe a busca pela perfeição te impedir de fazer um bom trabalho". Minha primeira reação foi pensar que aquilo simplesmente não fazia sentido, seja lá o que fosse a tal síndrome, já que buscando a perfeição, obviamente eu acabaria fazendo um bom trabalho. No entanto, na mesma época eu também passava por um processo de amadurecimento profissional forçado em que decidi aceitar toda crítica recebida independente de concordar ou não, buscando tirar algo positivo dela. Era mesmo possível que eu estivesse buscando algo desnecessário, ao menos para aquele contexto?

O arquiteto astronauta é aquele que vive no mundo da lua, fora da realidade, buscando soluções de outro mundo, vidrado demais em padrões e mais padrões, buscando sempre a solução mais perfeita possível sob o ponto de vista técnico. Para ele, se a solução pode ser melhorada, ela deve ser melhorada, e deve ser melhorada de imediato. Se uma tecnologia nova e interessante surge, ele vai querer usá-la, ainda que não tenha real necessidade. Se um novo padrão está bombando e se propõe a resolver o problema que ele enfrenta, ele irá querer usar tal padrão a qualquer custo. Assim cada vez mais novas tecnologias e padrões vão sendo agregadas a suas soluções, e dai começam a surgir as evidências de que sua super complexa, moderna e foda arquitetura, não é tão perfeita assim.

"Simples é melhor". "Mantenha isso simples, estúpido". "Você não vai precisar disso". São princípios listados entre as boas praticas que um bom arquiteto deve ter a obrigação de seguir, mas que normalmente são ignoradas pelo arquiteto astronauta. Hoje sei bem disso. Caso as ignore, suas soluções acabarão lotadas de tecnologias e padrões que tornarão seu código mais complicado de ser compreendido e modificado, a execução do software ficará mais lenta, dadas as camadas e mais camadas de abstração e linhas de execução, você mesmo ficará sobrecarregado em ter que gerenciar aquilo tudo.

Pra encerrar a história: Tenha sempre em mente a sua necessidade atual. Necessidades futuras mudarão, e suas soluções previamente implementadas podem se quer vir a atendê-las, quanto menos da melhor forma. "Você não vai precisar disso". Mantenha as suas soluções simples. Evite abstrações demais, que não se justifiquem na prática. E quanto aos princípios SOLID, lembre-se que eles existem para lhe orientar no processo de refatoração e melhoria de código, não no processo de construção. Evite otimizações antecipadas, antes de ter uma versão menos otimizada do código já funcionando, ou ainda, antes de identificar que tais otimizações são realmente necessárias. E o principal, evite criar situações apenas para lhe permitir usar um determinado padrão ou tecnologia. Não é por que programação distribuída lhe oferece diversas vantagens em diversos cenários que você deve executar cada procedimento em uma thread separada. Não é por que MongoDB é legal que você deve descartar o bom e velho Oracle sem pensar duas vezes.

Apague o seu código para torná-lo melhor

Menos é mais. Essa é uma máxima um pouco banal, mas as vezes é verdadeira. Uma das melhorias que tenho feito em nossa base de código nos últimos anos tem sido remover pedaços dela.

Escrevemos o software seguindo dogmas de XP, incluindo YAGNI (que quer dizer, You Aren’t Gonna Need It, Você Não Vai Precisar Disso). Mas sendo nossa natureza humana como é, inevitavelmente somos fracos em alguns pontos.

Observei que o produto estava levando muito tempo para executar certas tarefas, tarefas simples que deveria ser quase instantâneas. Isso por que estavam sobre-implementadas – enfeitada com firulas que não eram necessárias, mas que naquele momento pareciam ser uma boa ideia.

Então simplifiquei o código, melhorei sua performance, e reduzi o nível de entropia global do código simplesmente removendo as funcionalidades desnecessárias da base de código. Prestativamente, meus testes unitários me disseram que eu não havia quebrado nada durante essa operação. Uma experiência simples e plenamente satisfatória.

Mas por que o código desnecessário acabou lá em primeiro lugar? Por que um programador sentiu a necessidade de escrevê-lo, e como isso passou pelos processos de revisão de código e programação em pares? Quase certamente algo do tipo:

- Era um coisa legal de se escrever e o programador queria escrevê-la. (Dica: Escreva código porque agrega valor, não porque você que agrada);

- Alguém imaginou que isso seria necessário no futuro, então sentiu que seria melhor escrever isso já agora. (Dica: Isso não é. YAGNI. Se você não precisa disso agora, não escreva isso agora);

- Não parecia que o “extra” era tão grande assim, então seria mais fácil implementar isso agora do que ir até o cliente para ver se isso era realmente necessário. (Dica: Sempre leva mais tempo escrever e manter código extra. E o cliente na verdade é bem acessível. Uma pequena porção de código extra vira uma bola de neve com o tempo e se torna uma grande porção de código a ser mantido);

- O programador inventou requisitos extras que não estavam nem documentados nem discutidos para justificar a funcionalidade extra. O requisito era na verdade falso. (Dica: Programadores não definem requisitos, o cliente define);

No que você está trabalhando agora? Isso é realmente necessário?

Pete Goodliffe

97 Things Every Programmer Should Know: Collective Wisdom from the Experts, Kevlin Henney, O'Reilly Media, Fevereiro de 2010, pág. 78

Aprendizado Contínuo

Vivemos em tempos interessantes. À medida que o desenvolvimento é distribuído pelo mundo, percebemos que há muitas pessoas capazes de fazer o nosso trabalho. É preciso continuar aprendendo para se manter no mercado. Caso contrário, nos tornamos dinossauros, presos no mesmo trabalho, até que, um dia, deixamos de ser necessários ou temos nosso trabalho terceirizado para uma fonte mais barata de recursos.

Sendo assim, o que fazer a respeito? Alguns empregadores são generosos o suficiente para fornecer treinando para ampliar nosso conjunto de habilidades. Outros podem não ser capazes de dispor do tempo ou dinheiro para nos oferecer qualquer formação. Por segurança, precisamos assumir a responsabilidade sobre nossa própria educação.

Aqui está uma lista de dicas de como se manter atualizado. Muitas destas podem ser obtidas de graça na Internet:

• Leia livros, revistas, blogs, feeds do Twitter e sites. Se você quiser se aprofundar em um assunto, considere se juntar a uma lista de discussão ou de notícias.
• Se você realmente quiser ficar imerso em uma tecnologia, coloque a mão na massa – escreva algum código.
• Sempre tente trabalhar com pessoas mais experientes; ser o melhor pode paralizar seu aprendizado. Embora você possa aprender com qualquer pessoa, aprenderá muito mais com alguém mais inteligente ou mais experiente que você. Se não conseguir encontrar um mentor onde trabalha, considere seguir outros caminhos.
• Use mentores virtuais. Procure autores e desenvolvedores na Web que você goste de ler. Assine seus blogs.
• Conheça os frameworks e bibliotecas que você usa. Saber como algo funciona faz com que você saiba como usá-lo melhor. Se forem código aberto, melhor ainda. Use o depurador para percorrer o código para ver o que está acontecendo por baixo dos panos. Você vai começar a ver códigos escritos e revisados por pessoas realmente inteligentes.
• Sempre que você cometer um erro, corrigir um bug, ou tiver um problema, tente entender o que aconteceu. É provável que alguém já tenha passado pelo
mesmo problema e tenha postado na web. o Google é bastante útil nesse momento.
• Uma boa maneira de aprender algo é ensinar ou falar a respeito. Quando as pessoas lhe ouvem e lhe fazem perguntas, você fica mais motivado
a aprender. Tente ensinar algo a seus colegas de trabalho, em um grupo de usuários, ou em uma conferência local.
• Faça parte ou inicie um grupo de estudos ou um grupo de usuários para uma linguagem, disciplina ou tecnologia em que esteja interessado.
• Vá a conferências. E se não puder ir, muitas conferências disponibilizam suas palestras online gratuitamente.
• Vai fazer uma longa viagem? Ouça a um podcast.
• Você costuma executar alguma ferramenta de análise estática de código, ou verifica os warnings na sua IDE? Entenda o que eles estão relatando e por quê.
• Siga os conselhos do “The Pragmatic Programmer”* e aprenda uma nova linguagem a cada ano. Ou ao menos aprenda uma nova tecnologia ou ferramenta. Esses estudos podem lhe dar novas idéias, que você pode usar com suas tecnologias atuais.
• Nem tudo o que estudar tem de ser sobre tecnologia. Entenda o domínio em que está trabalhando, assim você poderá entender melhor os requisitos e
ajudar a resolver problemas de negócio. Aprender a ser mais produtivo, como trabalhar melhor, é outra boa dica.
• Volte para a escola. Faça um novo curso.

Seria bom ter a capacidade que tem o Neo, em Matrix, e simplesmente baixar as informações que precisamos para nossos cérebros. Mas não temos, por isso temos que assumir um compromisso mais longo de aprendizado. Você não precisa gastar cada hora acordado estudando. Um curto período, digamos uma vez por semana, já é melhor que nada. Há (e deve sempre haver) uma vida além do trabalho.

A tecnologia muda rapidamente. Não fique para trás.

Clint Shank

97 Things Every Programmer Should Know: Collective Wisdom from the Experts, Kevlin Henney, O'Reilly Media, Fevereiro de 2010, pág. 36.

Nada substitui o lucro

Se você é um programador apaixonado pelo que faz, já deve ter sofrido bastante ao ver seus chefes, coordenadores, gerentes, ou patrões ignorando questões técnicas de suma importância, para você, como a manutenção de um código fonte de qualidade por exemplo, para viabilizar o cumprimento de um prazo ou algum requisito contratual. Isso é realmente frustrante e deve lhe fazer reclamar bastante pelos corredores e reconsiderar sempre a possibilidade de mudar de emprego, certo?

Não adianta. Onde quer que vamos estamos sempre sujeitos a isso. Você pode até mesmo encontrar uma empresa bacana de se trabalhar, onde os valores técnicos são tão considerados quanto os valores gerenciais, mas se de repente essa empresa entra em crise, rapidamente começaram as demissões, estagiários brotando do chão, agilidade sendo substituída por métodos tradicionais e a qualidade sendo deixada novamente em segundo plano.

Nada substitui o lucro, e isso é algo que você desenvolvedor, por mais bem intencionado que esteja, por mais profissional que seja, e por mais comprometido que se mantenha com a qualidade do código que escreve, não deve deixar de considerar. E não veja isso como algo ruim, ou errado. De fato nada substitui o lucro. Nenhuma empresa é constituída com o objetivo de criar o melhor software se isso não for apenas um meio de levá-la ao lucro. No fim, o que toda empresa busca é o lucro. 

Como então criar software de qualidade se o que interessa à empresa para a qual você trabalha é apenas lucrar? Se um software porcamente feito for mais lucrativo, é isso que a empresa irá lhe demandar, certo? Nem sempre. Cada organização tem seus valores, e muitas já reconhecem que produto de baixa qualidade uma hora ou outra se reverterá em prejuízo. Mas se esse não for o caso da empresa em que você trabalha, não entre numa guerra por interesses que deveriam ser daqueles que lutam contra. Faça sua parte, coloque qualidade no que você faz, na medida em que for possível, e não seja perfeccionista demais, seja mais pragmático. Aprenda também a aceitar que muitas vezes o nível de qualidade necessário será muito inferior ao melhor que você tem capacidade de entregar. Entenda os objetivos do projeto, compartilhe deles, e dentro desse limite, faça o seu melhor.

5 segredos para um propósito compartilhado

Um dos pré-requisitos para um trabalho em equipe saudável e eficiente é sem dúvida ter um propósito compartilhado pela equipe. Abaixo listo 5 segredos elencados por Christopher Avery para facilitar esse objetivo.

1. Estabelecer um entendimento compartilhado:

Discuta cada tópico, a missão, os entregáveis, e o produto do trabalho de sua equipe, até que possam articular juntos uma descrição clara e comum de seu propósito.

2. Selecione sua equipe por sua motivação, não por suas qualificações.

Se trabalho em equipe é importante para você, olhe para as qualificações apenas após considerar diretrizes, energia, interesse, motivação e entusiasmo, por que é um desejo compartilhado, não taleto, que gera trabalho em equipe.

3. Aceite, de uma vez por todas, que colegas de equipe não precisam gostar uns dos outros.

Encorajar afinidade para uma tarefa compartilhada, não para um com o outro, é a maneira mais rápida e certa de criar forte coesão no grupo. Ao invés de usar exercícios e técnicas que promovam a amizade, faça todos adotarem um foco comum de modo que cada membro da equipe veja boas razões para trabalhar um com o outro.

4. Pare de tentar motivar.

Por que tentar motivar outras pessoas quanto isso é quase impossível? Ao invés disso, use a motivação que já existe nos membros da equipe perguntando a eles sobre suas necessidades e desejos.

5. Determine se seu time está "construído".

Um time "construído" compartilha direcionamento e energia. Para atingir esse status para seu time, coloque sua fundação bem cedo perguntando a você mesmo uma variedade de importantes questões. Qual é a tarefa da equipe? Qual o benefício para cada membro da equipe ao se comprometer com esse trabalho? Há acordos que permitam à equipe operar mais rapidamente e eficientemente? Os membros da equipe compartilham um objetivo comum que os inspire? Você sabe o que cada membro da equipe agrega ao time?

Você não pode ganhar todas

Muitas foram as vezes em que me frustrei ao tentar convencer a outros, em especial quando eram superiores hierárquicos, a adotarem uma solução proposta por mim. Na maioria das vezes, diante de um problema, o que eu fazia era elaborar a melhor solução que eu fosse capaz, analisava cada detalhe, não deixava nada de fora, e por fim apresentava aos interessados, muitas vezes nem tão interessados assim, um solução única. Obviamente não era uma solução perfeita, mas já era uma solução bastante questionada e analisada.

O resultado disso, na maioria das vezes, era uma rejeição com base em argumentos mal fundamentados, mal pensados, que não consideravam todo o contexto, que dava importância a fatos irrelevantes e desconsiderava os fatos realmente importantes. Obviamente esse tipo de rejeição é bastante revoltante. No entanto, isso é bastante comum de se ver em situações como essa. Mas há justificativa.

Muitas vezes nós de fato não demos os pesos certos aos fatores considerados, ao menos não segundo a ótica dos demais interessados. Outras vezes não temos todo o domínio do contexto, não conhecemos todos os fatos que serão considerados pelos tomadores de decisão. E outras vezes o tomador de decisão simplesmente erra feio mesmo. O fato é que não podemos ganhar todas. Perderemos muitas. Por motivos legítimos ou por motivos idiotas. Mas essa é a realidade.

Diante disso, já há algum tempo mudei minha tática e ao invés de me focar em obter uma única melhor solução para os problemas que me dedico a resolver, passei a elaborar e propor várias. Na maioria das vezes nenhuma delas trará o melhor resultado de imediato, muitas vezes deixaram a desejar, mas todas elas resultarão em uma realidade melhor que simplesmente continuar convivendo com o problema.

E o que observei com essa mudança de comportamento foi que agora vejo boa parte das minhas propostas sendo colocadas em prática, ainda que muitas delas continuem sendo rejeitadas por uma razão ou outra. Diante de problemas que sei ser capaz de ajudar a resolver, vejo pequenos avanços sendo dados, pequenas ideias sendo implementadas e fazendo a diferença.

Se você é uma pessoa pró-ativa como eu e que não consegue ficar inerte diante de um problema passível de solução, não tente elaborar uma solução fantástica que mudará a realidade para sempre. Pense em pequenos avanços, proponha pequenas mudanças, e proponha muitas delas. Se você for mesmo bom no que faz, aquelas que forem aceitas já poderão tornar a realidade um pouco melhor e lhe darão credibilidade para que seja ouvido novamente no futuro.

O que é um programador profissional?

A característica mais importante de um programador profissional é responsabilidade pessoal. Programadores profissionais assumem responsabilidade por suas carreiras, suas estimativas, seus compromissos com o cronograma, seus erros, e sua criação. Um programador profissional não passa essa responsabilidade para os outros.

• Se você é um profissional, então você é responsável por sua carreira. Você é responsável por ler e aprender. Você é responsável por estar atualizado com a industria e a tecnologia. Muitos programadores sentem que é responsabilidade de seus empregadores treiná-los. Desculpe, isso está simplesmente errado. Você acha que médicos se comportam assim? Você acha que advogados se comportam assim? Não, eles se treinam em seu próprio tempo, e com seu próprio dinheiro. Eles passam muitas de suas horas vagas lendo artigos e decisões. Eles se mantém atualizados. E assim devemos fazer. O relacionamento entre você e seu empregador é bem descrito no seu contrato de trabalho. Em resumo: seus empregadores se comprometem a lhe pagar, e você se compromete a fazer um bom trabalho.
• Profissionais assumem responsabilidade pelo código que escrevem. Eles não liberam código a menos que saibam que funciona. Pense sobre isso por um minuto. Como você pode considerar-se um profissional se pretende liberar código sobre o qual não está seguro? Programadores profissionais esperam que o QA não encontre nada por que eles não liberam seu código até que o tenham testado por completo. Claro, QA sempre encontra algum problema, por que ninguém é perfeito. Mas como profissionais, nossa atitude deve ser não deixar nada para o QA encontrar.
• Profissionais são jogadores de equipe. Eles assumem responsabilidade pela entrega de todo o time, não apenas pelo seu próprio trabalho. Eles ajudam um ao outro, ensinam um ao outro, aprendem um com o outro, e até mesmo substituem um ao outro quando necessário. Quando um colega de equipe está mal, os outros intervêm, sabendo que um dia serão eles que precisaram de ajuda.
• Profissionais não toleram grandes listas de bugs. Uma lista de bugs enorme é desleixo. Sistemas com milhares de issues em sistemas de issue-tracking são tragédias do descaso. De fato, em muitos projetos, a simples necessidade de um sistema de issue-tracking já é um sintoma de descaso. Apenas sistemas muito grandes deveriam ter uma lista de bugs tão longa que alguma automação seja necessária para gerenciá-la.
• Profissionais não fazem bagunça. Eles tem orgulho de sua criação. Eles mantém seu código limpo, bem estruturado, e fácil de ler. Eles seguem padrões acordados e boas práticas. Eles nunca, jamais se apressam. Imagine que você está tendo uma experiência fora do corpo assistindo um médico realizando uma cirurgia em seu coração aberto. Esse médico tem uma deadline (no sentido mais literal). Ele deve finalizar antes que a máquina de circulação artificial danifique demais as suas células vermelhas. Como você quer que ele se comporte? Quer que ele se comporte como um típico desenvolvedor de software, correndo e fazendo bagunça? Quer que ele diga, "Voltarei e corrigirei isso depois"? Ou quer que ele se atenha cuidadosamente a suas disciplinas, tomando seu tempo, confiante que sua abordagem é a melhor abordagem que ele pode razoavelmente tomar. Você quer uma bagunça, ou profissionalismo?

Profissionais são responsáveis. Eles assumem responsabilidade por suas carreiras. Eles assumem responsabilidade por fazerem seu código funcionar apropriadamente. Eles assumem responsabilidade pela qualidade de sua criação. Eles não abandonam seus princípios quando as deadlines os assombram. Na verdade, quando a pressão monta, profissionais se atém ainda mais forte às disciplinas que eles sabem serem corretas.

Robert C. Martin (Uncle Bob)

97 Things Every Programmer Should Know: Collective Wisdom from the Experts, Kevlin Henney, O'Reilly Media, Fevereiro de 2010, pág. 134.

Não posso resolver o seu problema se você só me informa a sua solução.

Imagino que todo desenvolvedor um pouco mais experiente já tenha passado por esse tipo de situação. Seu 'chefe' lhe apresenta um 'problema' e diz que você precisa resolvê-lo urgente. "Precisamos disso para a próxima versão." Algo do tipo:

"Preciso que crie essa tabela no banco, armazene tais valores e altere tal e tal tela para o usuário fazer o cadastro dos dados."

Nesses cenários o 'chefe' sabe bem o que está fazendo, domina a arquitetura do sistema, sabe que basta inserir a tabela no banco e alterar as telas de cadastro, certo?

Normalmente isso não costuma ser verdade. Questões técnicas quase sempre passam despercebidas no momento da elaboração da solução, em maior ou menor grau, e muitas vezes o desenvolvedor não se sente a vontade, ou se quer tem a opção de criticar a solução apresentada pelo 'chefe'. Ou pior, ele implementa tal solução sem perceber que haverá um impacto indesejado, que causará problemas futuros.

O grande problema nisso é o fato de o 'chefe' ter comunicado uma solução para um problema que ele se quer expôs ao desenvolvedor. Duas cabeças pensam melhor que uma. Quanto melhor a equipe conhecer o verdadeiro problema a ser resolvido, maior será a chance de alguém visualizar com antecedência os impactos negativos de se implantar uma ou outra solução.

Não é a toa que metodologias como o Scrum determinam que decisões técnicas ("soluções") sejam tomadas pelos desenvolvedores, cabendo ao Product Owner apenas a tarefa de especificar e priorizar os requisitos ("problemas").

Infelizmente essa é uma realidade que nem sempre podemos mudar. Mas em todo caso, na próxima vez que você receber uma tarefa ("solução") para implementar, pense se você tem total entendimento de qual é o problema que aquela solução se destina a resolver. Se não tiver esse entendimento, tente esclarecer os objetivos com os demais membros do time, com seu 'chefe', e quem mais puder ajudar. Não se acanhe. Quanto melhor você entender o problema, melhor capacitado estará para implementar uma solução, ainda que não seja você quem a defina.

Seja pragmático.

Referência: http://www.acceptancetesting.info/the-book/

O que constitui um programador pragmático?

Todo desenvolvedor é único, com pontos fortes e fracos, preferências e aversões. Com o tempo, cada um irá criar seu próprio ambiente. Esse ambiente irá refletir a individualidade do programador, assim como seus hobbies, roupas, corte de cabelo. No entanto, se você for um programador pragmático, você irá compartilhar muitas das seguintes características:

• Adotar cedo e adaptar-se rápido: Você tem um instinto por tecnologias e técnicas, e ama testar coisas novas. Quando diante de uma novidade, você será capaz de compreende-la rápido e integrá-la com o restante de seu conhecimento. Sua confiança nasce de sua experiência.
• Ser curioso: Você tende a fazer perguntas. Isso é bacana, como você fez? Você teve problemas com essa biblioteca? O que é esse BeOS do qual ouvi falar? Como links simbólicos são implementados? Você é um acumulador de detalhes, cada um podendo afetar alguma decisão anos a frente.
• Ser um pensador crítico: Você raramente aceita as coisas como dadas sem primeiro entender os fatos. Quando um colega diz "porque é assim que funciona," ou um fornecedor promete a solução para todos os seus problemas, você sente o cheiro de um desafio.
• Ser realista: Você tenta entender a real natureza de cada problema que enfrenta. Esse realismo lhe dá uma boa ideia de quão diferente as coisas são, e quanto tempo tomarão. Entender pro si próprio que um processo deve ser difícil ou vai tomar um tempo para ser concluído lhe dá estímulo para continuar.
• Atirar para todos os lados: Você se esforça para se familiarizar com todo tipo de tecnologia e ambiente, e trabalha para se manter atualizado. Embora seu trabalho atual exija que você seja um especialista, você sempre será capaz de seguir para novas áreas e novos desafios.

Deixamos a mais básica característica para o final. Todo programador pragmático a possui:

• Cuidar da sua criação.

Nós entendemos que não há sentido em desenvolver software a menos que você se preocupe em fazer isso bem feito.

• Pense! Sobre seu trabalho.

De modo a ser um programador pragmático, nós o desafiamos a pensar sobre o que faz enquanto faz. Isso não é uma análise única de suas práticas atuais, mas sim uma avaliação contínua de toda decisão tomada, a cada dia, em cada desenvolvimento. Nunca entre no piloto automático. Pense constantemente, criticando seu trabalho em tempo real. O velho lema da IBM, PENSE!, é o mantra do programador pragmático.

Se isso soa difícil pra você, então você está exibindo a característica de ser realista. Isso irá tomar boa parte do seu valioso tempo, tempo que provavelmente já está sob tremenda pressão. A recompensa é um envolvimento mais ativo com o trabalho que você ama, um sentimento de domínio sobre um crescente conjunto de assuntos, e prazer em sentir um crescimento contínuo. Ao longo do tempo, seu investimento será pago à medida em que você e sua equipe se tornam mais eficientes, escrevem códigos mais fáceis de manter, e gastam menos tempo em reuniões.

Andrew Hunt e David Thomas, The Pragmatic Programmer: From journeyman to master, Addison Wesley 1999. Pág. xviii

Pragmatismo e TDD

Anteontem, 05 de Março de 2013, Uncle Bob Martin, um dos principais defensores do desenvolvimento guiado por testes (TDD), fez uma crítica ao modo como são vistas as startups, jovens empresas que se aventuram, ousam, e se arriscam na busca do sucesso através da criação de softwares inovadores. 

Como resposta, alguns leitores tacharam o autor de ser muito dogmático a respeito da prática de TDD. E quem o conhece sabe que há alguma verdade nisso.

No dia seguinte, Uncle Bob publicou uma resposta onde apresentou o seu ponto de vista com relação ao pragmatismo vs dogmatismo no que se refere à prática de TDD, apontando situações em que ele é pragmático e não utiliza a técnica.

Segue abaixo, traduzido para nosso idioma:

Então, quando eu não pratico TDD?

• Não escrevo testes para getters e setters. Fazer isso normalmente é besteira. Tais getters e setters serão indiretamente testados por testes de outros métodos; então não há porquê testá-los diretamente.
• Não escrevo testes para variáveis membros. Elas também serão testadas indiretamente.
• Não escrevo testes para funções de uma só linha ou funções que são obviamente triviais. Novamente, elas serão testadas indiretamente.
• Não escrevo testes para GUIs. GUIs necessitam ajustes. Você tem que acertá-las no lugar alterando tamanho de fonte aqui, valores RGB ali, uma posição XY aqui, a largura de um campo ali. Fazer isso com testes primeiro é estupidez e perda de tempo.
• No entanto, me certifico que qualquer processamento relevante no código da GUI seja removido para módulos que sejam testáveis. Não permito que código relevante passe sem testes. Portanto meus códigos de GUI são pouco mais que colas e fios que enfiam os dados no seu lugar na tela (Veja artigos sobre MVVM e Model View Presenter).
• Em geral não escrevo testes para nenhum código que eu tenha que ajustar no lugar por tentativa e erro. Mas separo o código "ajustável" do código que estou mais certo de que escreverei testes.
• Ocasionalmente, ajusto código no lugar e então escrevo os testes posteriormente.
• Também ocasionalmente removo código "ajustado" e o reescrevo com testes primeiro.
• Qual abordagem escolher é uma questão de julgamento.
• Alguns meses atrás escrevi um programa inteiro de 100 linhas sem nenhum teste.
• O programa era para uma única execução. Seria usado uma vez e então descartado. (Era para um efeito especial em um de meus vídeos).
• O programa era todo relacionado à tela. Em essência, era um aplicativo GUI puro. Sendo assim eu tive que ajustar a coisa toda no lugar.
• Escrevi em Clojure, e portanto tinha REPL! Pude executar o programa à medida em que crescia a partir da REPL, e pude ver os resultados de cada linha de código que escrevia instantaneamente. Isso não era TDD, isso era EDD (Eye Driven Development).
• Normalmente não escrevo testes para frameworks, bancos de dados, web-servers, ou outra ferramenta de terceiros que supõe-se funciona. Crio mocks para essas coisas e testo o meu código, não o deles.

• Claro que as vezes testo códigos de terceiros se:
• Acredito que tenha defeitos.

• Os resultados são rápidos e previsíveis o bastante a ponto de criar um mock ser um exagero.

Não é tudo dogma.

Essa lista não está completa. Estou certo de que pensarei em outras vezes que não escrevi testes; mas o espirito dessa lista deve estar evidente. Pragmatismo entra em jogo quando fazemos TDD. Não é apenas dogma.

Entretanto, respeito o dogma; há uma razão para isso. Pragmatismo pode as vezes se sobresair; mas: Não escreverei nenhum código de produção relevante sem fazer todo esforço para usar TDD.

Uncle Bob Martin