No desenvolvimento de software, a dívida tecnológica (também conhecida como dívida digital, dívida técnica, dívida de design ou dívida de código) é um déficit ou custo implícito de retrabalho futuro necessário. Ela ocorre quando diante de um problema tecnológico, opta-se inicialmente por uma solução mais fácil, embora limitada e incompleta, ao invés de se adotar uma abordagem melhor e mais aprimorada que embora possa levar um pouco mais de tempo ou demandar um pouco mais de esforço para ser alcançada, não geraria um retrabalho futuro, ou seja, uma dívida tecnológica.
Analogamente à dívida monetária, se a dívida tecnológica não for paga, pode ir acumulando "juros" ao longo do tempo, dificultando cada vez mais a implementação de mudanças e evoluções. O déficit produzido pela dívida tecnológica não resolvida aumenta a entropia ou desordem do software e o custo de retrabalhos adicionais. Da mesma forma que a dívida monetária, a dívida tecnológica não é necessariamente uma coisa ruim e, às vezes (por exemplo, em uma prova de conceito) é algo necessário para se levar os projetos adiante. Por outro lado, alguns especialistas afirmam que a metáfora da "dívida tecnológica" tende a minimizar as suas implicações, o que resulta em uma priorização insuficiente do trabalho necessário para corrigi-la ou quita-la.
Dado que uma mudança é iniciada em uma base de código, muitas vezes há a necessidade de fazer outras mudanças coordenadas em outras partes da base de código ou documentação, ou até em outros sistemas relacionados. As alterações necessárias que não forem concluídas então passam a ser consideradas dívidas e, até serem pagas, incorrerão em juros sobre juros, dificultando a construção e a evolução de um projeto. Embora o termo seja usado principalmente no desenvolvimento de software, ele também pode ser aplicado a outras profissões e cenários.
Causas Causas comuns da dívida tecnológica incluem:
O desenvolvimento contínuo e a longa série de melhorias e mudanças de projetos ao longo do tempo tornam as soluções antigas abaixo do padrão ideal. Definição inicial insuficiente, na qual os requisitos ainda estão sendo definidos enquanto o desenvolvimento já se iniciou. Casos em que o desenvolvimento começa antes de qualquer esforço de elaboração e gestão da demanda. Isso é feito para economizar tempo, mas geralmente ocasiona a necessidade futura de retrabalho. As pressões de negócios, em que o negócio considera lançar algo antes que as implementações e mudanças necessárias sejam concluídas, produzem déficit tecnológico envolvendo essas mudanças incompletas.
Falta de processo ou compreensão tecnológica, nos quais as empresas ou organização são "cegas" ao conceito de dívida tecnológica e tomam decisões sem considerar suas implicações futuras. Componentes fortemente acoplados, onde as funções não são modulares e o software não é flexível o suficiente para se adaptar às mudanças nas necessidades do negócio. Falta de um conjunto de testes, que incentiva correções rápidas e arriscadas de bugs com "gambiarras". Falta de documentação de software, onde o código é criado sem documentação de suporte. O trabalho para criar a documentação necessária representa uma dívida. Falta de colaboração entre as equipes, onde o conhecimento não é compartilhado em toda a organização e a eficiência do negócio é prejudicada, ou os desenvolvedores iniciantes não são devidamente orientados. O desenvolvimento paralelo em várias ramificações acumula dívida tecnológica devido ao trabalho necessário para se mesclar as alterações em uma única base de código. Quanto mais mudanças feitas isoladamente, mais dívidas. Refatoração adiada. À medida que os requisitos de um projeto evoluem, pode ficar claro que partes do código se tornaram ineficientes ou difíceis de editar e devem ser refatoradas para dar suporte a requisitos futuros. Quanto mais a refatoração demorar e quanto mais código for adicionado, maior será a dívida.
Falta de alinhamento com os padrões, onde recursos, frameworks e tecnologias padrões de mercado são ignorados. Eventualmente, a integração com os padrões virá e fazê-lo mais cedo custará menos (semelhante à "refatoração adiada").
Falta de conhecimento, quando o desenvolvedor não sabe escrever código adequado. Falta de propriedade, quando as demandas de software terceirizadas resultam na necessidade de uma revisão ou reengenharia interna para refatorar ou reescrever o código terceirizado. Liderança tecnológica pobre, onde decisões mal pensadas ou sem propriedade das implicações tecnológicas são transmitidas na cadeia de comando. Mudanças de especificação de última hora. Eles têm potencial para causar impacto em todo o projeto, mas geralmente não há tempo ou orçamento suficientes para se documentar e testar todas as mudanças necessárias.
Reparar ou quitar a dívida tecnológica Kenny Rubin usa as seguintes fases possíveis de itens da dívida tecnológica, no que se refere a identificação e reparo:
Dívida tecnológica descoberta ao acaso — um débito que a equipe de desenvolvimento desconhecia existir até que foi exposto durante o curso normal da execução do trabalho no produto. É uma dívida que era desconhecida até então. Por exemplo, a equipe está adicionando um novo recurso ao produto e, ao fazê-lo, percebe que uma solução inadequada havia sido incorporada ao código anos antes por alguém que já partiu há muito tempo da instituição. Dívida tecnológica conhecida — dívida que é do conhecimento da equipe de desenvolvimento e foi dada visibilidade dentro das demais equipes da organização, mas ainda não foi endereçada. Dívida tecnológica endereçada — dívida que é conhecida e já está no backlog para atendimento e reparo pela equipe de desenvolvimento.
Consequências Os "pagamentos de juros" da dívida tecnológica são os "custos" que são gerados por ela ao longo do tempo. Estes custos surgem na forma de necessidade de manutenção frequente para que o software funcione minimamente conforme o esperado, ou surgem também pela ausência de manutenção do mesmo apesar dos problemas existentes. Neste último caso, os problemas tendem a aumentar com o tempo e tendem a gerar custos extras, como por exemplo, custos adicionais de suporte pelo aumento do número de chamados abertos pelos usuários ou custos de desenvolvimento futuros maiores pela qualidade cada vez mais afetada. Quanto mais se adia a resolução da dívida tecnológica, mais ela se eleva e maior será seu custo de quitação no futuro. Ainda mais se o software em questão estiver sofrendo modificações. Paga-se a dívida simplesmente concluindo-se o trabalho necessário para sanar os problemas e os déficits existentes.
O acúmulo de dívida tecnológica é uma das principais causas de atrasos nos projetos. É difícil estimar exatamente quanto trabalho é necessário para se saldar a dívida. Para cada mudança iniciada, uma quantidade incerta de trabalho incompleto é comprometida com o projeto. Porque as incertezas vão se acumulando. O prazo é perdido quando o projeto percebe que há mais trabalho incompleto (dívida) do que tempo para concluí-lo. Para ter cronogramas de lançamento previsíveis, uma equipe de desenvolvimento deve limitar a quantidade de trabalho em andamento para manter a quantidade de trabalho incompleto (ou dívida) pequena o tempo todo.
Se o critério de aprovação de um software é apenas o trabalho concluído, então este projeto pode ser lançado com uma quantidade substancial de dívida tecnológica, pois apenas um critério superficial foi considerado. Se esse software chegar à produção, os riscos de se implementar quaisquer refatorações futuras para sanar a dívida tecnológica aumentam drasticamente. A modificação do código de produção acarreta o risco de interrupções, perdas financeiras reais e possivelmente repercussões legais se os contratos envolverem acordos de nível de serviço (SLA). Por esse motivo, podemos ver a transposição da dívida tecnológica para a produção quase como se fosse um aumento na taxa de juros e a única forma de diminuir essa taxa seria quando estes softwares em produção são desativados ou inteiramente substituídos.
Embora a Lei de Manny Lehman já indicasse que os programas em evolução têm sua complexidade e deterioração estrutural aumentadas, a menos que seja feito um trabalho para mantê-las, Ward Cunningham foi o primeiro a traçar uma comparação entre complexidade técnica e dívida tecnológica em um relatório de 1992:
Em seu texto de 2004, Refatoração para Padrões, Joshua Kerievsky apresenta um argumento comparável sobre os custos associados à negligência arquitetural de software, que ele descreve como "dívida de design".
As atividades que podem ser adiadas, ou negligenciadas, incluem documentação, roteiros de testes, implementações das seções de código incompletas, tratamento dos alertas emitidos pelos compiladores das linguagens e análises estáticas de código. Outros aspectos que produzem dívida tecnológica incluem o conhecimento que não é compartilhado pela organização e código que é muito confuso para ser facilmente modificado.
Escrevendo sobre o desenvolvimento do PHP em 2014, Junade Ali disse:
Grady Booch compara como a evolução das cidades é semelhante à evolução dos sistemas de alta demanda por software e como a falta de refatoração pode levar à dívida tecnológica.
No software de código aberto, postergar o envio de alterações locais para o projeto upstream é uma forma de dívida tecnológica.
Ver também Antipadrão Escalada de irracional de compromisso Deterioração de software Código espaguete Custo irrecuperável
Categoria:Manutenção de software Categoria:Metáforas Categoria:Engenharia de software