Pagar à vista ou assumir os juros:
Como o débito técnico pode inviabilizar o seu software
Quando Ward Cunningham cunha o termo Débito Técnico em uma conversa com um stakeholder não técnico, ele faz uma analogia com uma dívida bancária. Imagine que para comprar uma casa ou um bem de alto valor, se tenham duas formas de pagamento. A primeira delas é juntar o valor necessário para a compra do bem ao longo do tempo e pagá-lo à vista, já a segunda maneira, mais imediatista, é fazer uma dívida bancária e ter o bem no mais curto prazo e ir pagando a dívida ao longo do tempo.
A diferença entre as duas formas de pagamento se dá pelo juro bancário. O banco tem que ganhar alguma coisa com a transação. Martin Fowler, em um artigo sobre débito técnico, fala sobre o juro bancário como o tempo extra necessário para desenvolver uma nova funcionalidade num software com muito lixo (débito técnico). Ele sintetiza a ideia exemplificando que se uma funcionalidade duraria 4 dias para ser desenvolvida num software livre de lixo, em um outro com bastante lixo demoraria 6 dias. A diferença de dias é o juro da dívida.
Segundo o CISQ (Consortium for IT Software Quality), o custo de softwares de baixa qualidade (CPSQ) nos Estados Unidos em 2020 foi de aproximadamente US$ 2.08 trilhões. Foi observado, que cerca de US$ 1.31 trilhão é o custo futuro para tratamento direto de débito técnico, um aumento de 14% em relação ao estudo realizado em 2018.
Atributos de Qualidade de Software como indicadores
Quando falamos em qualidade de software, podemos citar atributos importantes que a podem mensurar, segundo a ISO/IEC 9216:
- Funcionalidade: A capacidade de um software prover funcionalidades que satisfaçam o usuário em suas necessidades declaradas e implícitas, dentro de um determinado contexto de uso.
- Confiabilidade: A capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas.
- Usabilidade: A capacidade do produto de software de ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas.
- Eficiência: O tempo de execução e os recursos envolvidos são compatíveis com o nível de desempenho do software.
- Manutenibilidade: A capacidade (ou facilidade) do produto de software ser modificado, incluindo tanto as melhorias ou extensões de funcionalidade quanto às correções de defeitos, falhas ou erros.
- Portabilidade: A capacidade do sistema ser transferido de um ambiente para outro.
A ausência ou baixo índice desses atributos num software ressaltam sua baixa qualidade. Ao adentrarmos para a análise do débito técnico em si, que é uma das evidências de baixa qualidade, quando em demasia, podemos citar alguns sintomas:
- A ausência de:
- Testes Automatizados;
- Padrão de Codificação;
- Arquitetura de Software;
2. Código “hard coded” (sem design pattern);
O tempo necessário para inserir uma nova funcionalidade num código “hard coded” é muito maior se comparado a um código estruturado e dividido em pequenos componentes, por exemplo. Além de que, o custo associado ao tempo necessário para produção de features em um ambiente sem design é crescente ao longo do tempo, tendo em vista o pagamento dos juros.
De quem é a culpa pelo Débito?
Os possíveis responsáveis para a inserção de débito técnico no código fonte de uma aplicação, consequentemente, pontos de atenção para todo gerente de projeto, geralmente, são:
- A incongruência entre a gerência e a velocidade do time de desenvolvimento;
- A ausência de alinhamento entre os time de UI/UX e desenvolvimento;
- As más decisões de projeto;
- As más decisões do time de desenvolvimento;
- A baixa cobertura de testes;
- O baixo nível de senioridade do time de desenvolvimento;
Embora pareça fácil a distinção entre os tipos de pagamento e a escolha por qual caminho seguir, não é uma decisão trivial. Ter o bem de maneira imediata, ou no nosso caso ter uma funcionalidade do sistema o mais rápido possível, pode determinar o futuro de uma aplicação e/ou de uma organização. O time to market nesses casos, geralmente, dita a regra.
O Quadrante do Débito Técnico
O Quadrante do Débito Técnico é apresentado por Martin em outro artigo intitulado Technical Debt Quadrant. Nesse artigo, ele comenta sobre como a dívida técnica pode ser feita de maneira consciente, intencional e prudente e também o oposto.
Assumir o risco da dívida em detrimento da velocidade de maneira consciente e quantificada é um caminho prudente a seguir num contexto de alta velocidade de produção, nesse aspecto manter-se no primeiro quadrante em que Martin definiu.
O segundo quadrante revela a pior face do débito, quando se sabe a importância do código limpo e de boas práticas de design, e mesmo assim segue-se o caminho da velocidade e do lixo.
Os quadrantes inferiores refletem as dívidas não intencionais, relacionadas à imaturidade do time, quando não se tem conhecimento suficiente para adotar boas práticas ou quando não se tem experiência o suficiente.
No último quadrante, Martin ressalta o quão demorado pode ser a formação do conhecimento necessário para dizer como um projeto deveria ser construído. Ele salienta ainda, que durante a construção da aplicação estamos o tempo todo aprendendo sobre ela e portanto assim que terminamos, descobrimos como ela de fato deveria ser construída e uma série de débitos inadvertidos.
A Amortização
O lucro associado ao pagamento da dívida está relacionado à amortização. Diminuir a quantidade de juros pagos, resulta numa melhora da velocidade de entrega de novas funcionalidades. Existem algumas formas de amortização da dívida, das quais uma ou mais podem ser adotadas:
- Investir em qualificação profissional para o time;
- Parar a geração de novos débitos e começar a tratar os existentes;
- Mover todo o time para resolver os débitos;
- Contratar um time para lidar com os débitos;
- Jogar tudo fora e recomeçar;
O último método pode aparentar ser muito drástico, entretanto, em alguns casos é muito mais lucrativo recomeçar do que continuar tentando inserir mais funcionalidades num código fonte com muito lixo, o juro passa a ser inviável.
Fazer a amortização é um processo que pode ser demorado e aparentemente não lucrativo, já que o foco não vai ser criar funcionalidades que agregam valor ao sistema. À vista disso, a discussão do que é ou não débito e o que é lucrativo pagar também é grande entre comunidade ágil.
Uncle Bob fala que bagunça não é dívida. O argumento utilizado por ele é que um código confuso e ausente de boas práticas de design não é uma dívida técnica. A dívida técnica deve ser reservada para os casos em que as pessoas tomaram uma decisão ponderada de adotar uma estratégia de design que não é sustentável no longo prazo, mas produz um benefício de curto prazo.
Em comentário sobre o artigo de Uncle, Martin diz que para ele a questão de saber se uma falha de projeto é ou não uma dívida é uma questão equivocada. Ele considera que a questão central está associada à metáfora inicial da dívida, se ela é ou não útil para pensar em como lidar com problemas de design e em como comunicar esse pensamento. Ele ainda ressalta que o benefício direto da metáfora está associado à comunicação com pessoas não técnicas.
O consenso se dá no quão importante é pagar a dívida o mais rápido possível. Uncle diz que a geração de débito técnico exige uma necessidade de uma limpeza ainda maior e quando você assume uma dívida técnica, o melhor a se fazer é certificar-se de que seu código permaneça sempre limpo.
Para além do juro, um software limpo promove uma série de ganhos indiretos para o time:
- Engajamento;
- Prevenção de doenças psicológicas como ansiedade e síndrome de burnout;
- Crescimento das habilidades técnicas;
- Ambiente de trabalho agradável e saudável;
Todos ganham direta ou indiretamente com o pagamento da dívida e com um código fonte sustentável.
E você, já lidou com alto nível de débito técnico numa aplicação? Conseguiu tratar? Qual foi a forma que você encontrou para atacar os débitos e pagá-los? Já percebeu que a melhor forma de tratar era jogar tudo fora e recomeçar?
Para refletir:
- Será que é realmente lucrativo pagar todos os débitos técnicos de uma aplicação, mesmo os em módulos pouco críticos e que entregam baixo valor.
- Em análise de Time to Market, Otimização Prematura ou Débito Técnico: Qual caminho é o mais rentável?
