Dan North apresentou recentente em seu blog as implicações do custo de oportunidade no desenvolvimento de software, que se refere nesse contexto à escolha de uma solução em detrimento a outra, menos óbvia, que pudesse apresentar vantagens. Os engenheiros de software estão sujeitos ao custo de oportunidade diariamente, pois constantemente enfrentam situações que demandam a tomada de decisões.
Para reforçar seu argumento, North sugere o seguinte exercício:
Pense numa prática ou técnica que você utiliza quando desenvolve software, talvez sua prática favorita. Pensou?
Parte 1: Pergunte-se porque você faz isso e quais são os benefícios? Anote a resposta.
Parte 2: Onde você não utilizaria essa prática? Existem práticas alternativas? Anote alguns prós e contras de cada uma.
Como ilustração, North utiliza a prática de desenvolvimento orientado a testes (TDD), que considera um das práticas mais "dogmaticamente defendidas". Para ele, os custos de oportunidade associados ao TDD vêm da necessidade de confiança na realização de mudanças na base de código, do design emergente, da criação de testes automatizados e da utilização de testes como "documentação viva".
De acordo com um exemplo de uma aplicação para negociação de ações no mercado financeiro, em que poderia ser útil testar diferentes cenários e esboços de soluções, a aplicação de TDD pode incorrer em custos elevados e acréscimos de tempo. Em TDD, o design emergente está mais relacionado à busca por otimizações locais; enquanto que para encontrar uma melhor solução global pode ser necessário repensar a aplicação radicalmente. Por fim, North destaca que a utilização de testes automatizados como "documentação viva" pode gerar uma série de ruídos desnecessários.
Dan North conclui seu artigo com a seguinte recomendação:
Não aceite nada por seu "valor de face". Considere as vantagens e desvantagens de cada decisão, pois esses trade-offs existem, você os enxergando ou não. E se aprender como identificá-los, você pode ter ótimos resultados.
Alguns leitores concordam com os argumentos de North. Gene Hughson explica:
Adotar uma tecnologia ou técnica, sem consideração adequada sobre os custos e benefícios, é uma receita para o desastre.
Já outros leitores têm uma opinião diferente. Liz Keogh apoia as observações realizadas no artigo e sugere que as pessoas que seguem cegamente o desenvolvimento ágil sejam mais abertas a opiniões diferentes:
Vejo nesses comentários algumas pessoas que já caíram na armadilha de achar que se algo não está funcionando para alguém, essa pessoa deve estar fazendo algo errado. É um sentimento que notei em alguns blogs sobre agilidade, particularmente em torno de TDD, mas também com o Scrum. Existem muitos contextos, desde o lançamento de um aplicativo de controle de alocação até a correção de um bug urgente, em que o TDD simplesmente não é apropriado; e muitos também em que é uma boa prática, mas não está entre as melhores.
Embora nem todos estejam de acordo com os argumentos de North, especialmente em relação ao TDD, seu artigo expõe uma nova perspectiva relevante. Como Justin diz:
O artigo força o leitor a sair de sua zona de conforto, desafiando aquilo que você acredita. Estou certo de que muitas equipes bem sucedidas pegam pedaços de todos os métodos e os colocam juntos para construir uma equipe produtiva.
Veja mais no InfoQ Brasil sobre as recomendações de Dan North quanto à responsividade e entregas efetivas.