Investimentos técnicos em engenharia de software

A visão oposta da dívida técnica

No mundo da engenharia de software, existe uma analogia com o mundo financeiro.

A analogia se chama dívida técnica (em inglês technical debt).

A idéia é a seguinte.

Imagine que você faz uma compra (de um novo computador, por exemplo) e você parcela a compra no cartão de crédito em dez vezes.

Na data da cobrança do primeiro mês, você não realiza o pagamento, ou paga-o parcialmente.

Neste caso, juros são cobrados sobre o valor não pago.

No mês seguinte, ocorre o mesmo, e mais juros são cobrados, porém, agora sobre um montante maior, visto que a dívida já havia aumentado no mês anterior devido ao não-pagamento ou pagamento parcial.

Se tal ciclo continua a ocorrer, em algum momento a dívida pode não ser mais viável de ser paga, pois o valor extrapola os seus limites. É o famoso “poder” dos juros compostos.

No mundo do software, você pode iniciar um projeto novo sem se preocupar com questões como testes automatizados, revisão de código, integração contínua, propriedade coletiva de código, dentre outras disciplinas.

E no início, quem sabe isso até “lhe ajude” a realizar entregas mais rápidas.

Porém, lamento te informar, mas isto é uma ilusão.

Tal modelo não se sustenta no longo prazo e uma hora você terá que pagar os juros.

Mudanças em uma parte do software quebrarão outras as quais pensávamos não serem relacionadas.

Clientes começarão a reclamar de atrasos nas entregas, bugs em produção, problemas de segurança, etc.

E a “bola de neve” só aumenta, até o ponto que a única opção é jogar todo o esforço fora e começar tudo do zero.

Os juros compostos não perdoam, seja no mundo das finanças, seja no mundo da engenharia de software.

E se olhássemos para estes conceitos sob uma perspectiva invertida.

No mundo das finanças, podemos investir capital todos os meses por um certo período de tempo (por exemplo, por 30 anos) e no futuro, teremos uma “grana” guardada para a aposentadoria.

Uma pessoa pode decidir fazer investimentos mensais de R$100,00 por este período de 30 anos.

Ao final dos 30 anos ela terá uma determinada quantia.

Outra pessoa, pode investir mensalmente um valor de R1500,00 pelo mesmo período de tempo. 

E ao final dos 30 anos, terá uma quantia consideravelmente maior que a pessoa que investiu os R$100,00 mensais.

Os juros compostos rendem mais sobre maiores quantias, só que dessa vez, em vez de dívidas, estamos falando de investimentos. Ou seja, juros sendo pagos à você!

Você está conscientemente reservando capital para investimento mensal por um período de tempo, pensando no longo prazo.

Voltando para o mundo do software…

Um time pode investir em testes automatizados de interface gráfica de usuário para aplicações web e mobile.

Porém, tais testes são “disparados” manualmente por QAs apertadores de botão e analisadores de testes flaky (os famosos testes não-determiníscos, e por consequência, não confiáveis).

Os ganhos são pequenos e não impactam o sistema como um todo.

Outro time, no entanto, pode decidir por um processo mais robusto, com verificações e testes automatizados em diversas camadas da aplicação (análise estática de código, testes de unidade, testes de componentes, de APIs, de integrações, testes visuais, testes de frontend, end-to-end, testes de contratos, de desempenho, etc).

Além disso, tal equipe investe em uma infraestrutura que possibilita a execução de todas estas verificações em um pipeline de integração contínua omitizado para que o feedback seja rápido e confiável.

A mesma equipe também “investe” em um processo de revisão de código, que só ocorre quando todas as verificações anteriores passam.

Quando um bug é identificado, tal equipe pára tudo que está fazendo para resolver o problema o quanto antes possível. E fazem isso pois entendem que tal prática é um “investimento”. Isso já faz parte do modo da equipe operar (do seu modus operandis).

Quando aplicadas de forma pensada e com uma visão de longo prazo, tais práticas podem (e devem) ser consideradas como investimentos na saúde do projeto ao longo de sua existência.

O projeto vai crescendo (e por consequência sua complexidade), porém, as práticas de engenharia ao seu redor permitem que a velocidade das entregas não seja comprometida, que inconsistências sejam encontradas antes de “caírem nas mãos” dos clientes ou usuários do software, e acima de tudo, que as pessoas trabalhando no desenvolvimento de tais sistemas estejam felizes e saudáveis.

Essa idéia estava na minha cabeça desde um bate-papo sobre Programação Extrema com o Wagner Fusca (o qual recomendo você assistir) e estou feliz em compartilhá-la contigo.

E você, está investindo no longo prazo e saúde do projeto de software no qual trabalha, ou está pagando juros das dívidas técnicas que nunca são priorizadas?

Deixa um comentário. Estou curioso para saber o que achou deste conteúdo.

Até a próxima! 👋