Todos os projetos de software em que já trabalhei têm dívida técnica acumulada ao longo do tempo:
A dívida técnica é uma metáfora maravilhosa desenvolvido por Ward Cunningham para nos ajudar a pensar sobre esse problema. Nessa metáfora, fazer as coisas de forma rápida e suja nos coloca em uma dívida técnica, que é semelhante a uma dívida financeira. Assim como uma dívida financeira, a dívida técnica incorre em pagamentos de juros, que vêm na forma do esforço extra que temos de fazer no desenvolvimento futuro por causa da escolha do design rápido e sujo. Podemos optar por continuar pagando os juros ou podemos pagar o principal refatorando o design rápido e sujo para um design melhor. Embora seja caro pagar o principal, ganhamos com a redução dos pagamentos de juros no futuro.
A metáfora também explica por que pode ser sensato adotar a abordagem rápida e suja. Assim como uma empresa contrai uma dívida para aproveitar uma oportunidade de mercado, os desenvolvedores podem contrair uma dívida técnica para cumprir um prazo importante. O problema muito comum é que as organizações de desenvolvimento deixam que suas dívidas saiam do controle e gastam a maior parte de seu esforço de desenvolvimento futuro pagando juros altíssimos.
Não importa o quanto os desenvolvedores de software sejam talentosos e inteligentes, todos esses pequenos adiamentos começam a se acumular e a pesar cumulativamente sobre o projeto, arrastando-o para baixo. Meu projeto mais recente não é diferente. Depois de seis sólidos meses trabalhando na base de código do Stack Overflow, este é o exatamente onde estamos. Estamos nos preparando para uma grande refatoração do nosso banco de dados. Temos que parar de trabalhar em novos recursos por um tempo e pagar parte de nossa dívida técnica.
Acredito que o acúmulo de dívida técnica é inevitável em qualquer projeto de software real. Claro, o senhor refatorar à medida que o senhor avançae incorporar melhorias sempre que possível, mas é impossível prever exatamente como as principais decisões que o senhor tomou no início do projeto serão executadas. Tudo o que o senhor pode fazer é seguir o ritmo e reservar algum tempo no cronograma para pagar periodicamente sua dívida técnica.
O tempo que o senhor tira do cronograma para fazer pagamentos de dívidas técnicas normalmente não resulta em nada que os clientes ou usuários vejam. Às vezes, isso pode ser difícil de justificar. Na verdade, tive que defender nossa decisão com Joel, meu parceiro de negócios. Ele preferia que trabalhássemos em uma coisa maluca que ele chama de geração de receita, seja lá o que isso for.
Steve McConnell tem um uma longa entrada no blog examinando o débito técnico. Os perigos de não reconhecer sua dívida são claros:
Uma das implicações importantes da dívida técnica é que ela deve ser atendidoou seja, quando o senhor contrai uma dívida, há cobrança de juros. Se a dívida crescer o suficiente, a empresa acabará gastando mais com o serviço da dívida do que investindo no aumento do valor de seus outros ativos. Um exemplo comum é uma base de código legado na qual é necessário tanto trabalho para manter um sistema de produção em funcionamento (ou seja, “pagar a dívida”) que sobra pouco tempo para adicionar novos recursos ao sistema. Com relação à dívida financeira, os analistas falam sobre o “índice de endividamento”, que é igual à dívida total dividida pelo total de ativos. Índices mais altos de endividamento são vistos como mais arriscados, o que parece ser verdade também para o endividamento técnico.
Além do que Steve descreve aqui, eu também diria que a dívida técnica acumulada se torna um grande desestímulo para trabalhar em um projeto. É uma coleção de coisas pequenas, mas irritantes, com as quais o senhor tem de lidar toda vez que se senta para escrever código. Mas são exatamente esses pequenos aborrecimentos, essa areia moendo nas engrenagens do seu dia de trabalho, que acabam fazendo com que o senhor deixe de gostar do projeto. Essas pequenas coisas são importantes.
Pode ser assustador entrar e reconstruir uma grande quantidade de código funcional que se tornou complicado com o tempo. Mas não sucumba ao medo.
Não devo temer.
O medo é o assassino da mente.
O medo é a pequena morte que traz a obliteração total.
Vou enfrentar meu medo.
Permitirei que ele passe por cima de mim e através de mim.
E quando ela tiver passado, voltarei o olho interior para ver seu caminho.
Onde o medo tiver ido, não haverá nada.
Somente eu permanecerei.
Quando chegar a hora de pagar sua dívida técnica, não tenha medo de quebrar as coisas. É libertador, e até mesmo energizante, destruir o código para construí-lo mais forte e melhor do que era antes. Seja corajoso e perceba que pagar sua dívida técnica de vez em quando é uma parte normal e necessária do ciclo de desenvolvimento de software para evitar o pagamento maciço de juros mais tarde. Afinal de contas, quem quer viver para sempre?