Dívida Técnica - exposta

O significado e a origem da “dívida técnica”

A metáfora da Dívida Técnica (TD) no contexto do software foi cunhada por Ward Cunningham, que na época estava trabalhando na codificação de um sistema financeiro. Ele usou a metáfora para explicar aos seus colegas financeiros o raciocínio para refatorar e reescrever partes dos códigos à medida que o conhecimento dos requisitos evoluía.

“Ao tomar atalhos e entregar código que não é adequado para a tarefa de programação do momento, uma equipe de desenvolvimento incorre em TD. Essa dívida diminui a produtividade. Essa perda de produtividade é do interesse do DT.”

A explicação original pretendida por Ward era bastante restrita e específica, mas a metáfora agora ganhou vida própria:

Hoje em dia a Dívida Técnica significa várias coisas:

• Código que precisa ser alterado para eliminar atalhos problemáticos, que foram criados antes da nossa compreensão evoluída do que é necessário. (significado original).
• Código com bugs.
• Defeitos na arquitetura e nos projetos que foram atalhos criados por decisões táticas
• Código difícil de manter
• Código que depende de bibliotecas, sistemas operacionais ou outros componentes técnicos desatualizados
• Defeitos nos requisitos que foram criados porque foram tomados atalhos na compreensão dos requisitos.

A distinção entre dívida tecnológica, legado e obsolescência de software:

Sistemas legados

TD geralmente trata de atalhos técnicos que foram tomados e que estão causando problemas. Aplicativos e componentes de software antigos, construídos com base em tecnologias que não seriam escolhidas agora, são frequentemente classificados como sistemas legados. No momento em que foram construídos, os atalhos podem não ter sido tomados, portanto não haveria dívida tecnológica ali. Muitas vezes as pessoas classificam erroneamente um sistema legado como dívida tecnológica, quando na verdade ele pode estar quase obsoleto. Se um sistema legado tiver interfaces adequadas com outros sistemas e desempenhar sua função principal sem falhas, ele pode ser legado, mas não pode ser TD nem obsoleto. Quando um sistema deixa de servir o negócio, embora tenha servido durante algum tempo, consideramos que isto é um problema. obsoleto sistema, não necessariamente TD.

Obsolescência de Software

O valor de um software para uma organização diminuirá com o tempo. Após anos de uso, é provável que o argumento comercial para manter o sistema antigo diminua. O aplicativo tem vida útil e, eventualmente, é mais econômico desativá-lo ou substituí-lo do que mantê-lo funcionando. O software se torna obsoleto quando o ambiente operacional que ele precisa para executar deixa de ser compatível (hardware, sistema operacional, bibliotecas) ou quando o próprio software não atende mais ao propósito para o qual é necessário.

Depois que um novo software é escrito e implantado, é prudente que os executivos planejem alguns anos de atualizações e planejem sua eventual retirada/substituição. A vida útil econômica de um software varia. Alguns tipos de software tornam-se obsoletos após apenas alguns anos (muitos softwares de consumo), enquanto outros só podem tornar-se obsoletos após décadas (por exemplo, sistemas bancários COBOL ou sistemas de registo em geral). Obsolescência não é o mesmo que dívida tecnológica. Um software muito confiável pode se tornar obsoleto e ainda assim não ter TD.

O custo da dívida técnica

Continuando com a metáfora financeira podemos dizer que para algumas aplicações de software, a taxa de juro desse TD pode ser muito elevada, enquanto para outras pode ser mais baixa. Se o custo para a empresa de não resolver o problema for baixo, então a taxa de juros do TD será baixa. O custo geral do TD varia dependendo do seu impacto na operação e nas direções do negócio. Tomemos por exemplo um projeto onde estão sendo tomados atalhos com a qualidade dos requisitos. A consequência disso é que o software TERÁ que ser reescrito antes de entrar no ar. Esta é uma criação tola de DT, que provavelmente será evitável – e ajuda bastante a explicar por que alguns projetos de software que negligenciam os requisitos atrasam-se ou falham. É necessária uma abordagem caso a caso para a avaliação de impacto, mas pode ser considerada uma abordagem mais genérica para o dimensionamento da dívida.

Dimensionamento COSMIC da dívida técnica

O código TDin pode ser medido em CFP.

O modo como o TD surge pode ser devido a requisitos inadequados, decisões de arquitetura e design e atalhos. Isso então se transforma em código que faz a coisa errada ou de uma maneira que causará funcionalidade inadequada.

Quantificando a Dívida Técnica

Estas são as perguntas que os executivos prudentes deveriam fazer:

• Qual é o tamanho do TD?
• Qual será o custo se não consertarmos?
• Qual é o custo se o fizermos?

Para organizações que executam centenas de aplicações com dados operacionais e estratégicos, é útil normalizar a resposta a estas questões para que os investimentos para abordar o DT possam ser priorizados.

Tamanho e custo de reparo

O dimensionamento funcional é uma excelente abordagem para padronizar o dimensionamento do TD. A unidade de medida é o Ponto de Função CÓSMICO ou Ponto de Função. Por exemplo, o aplicativo tem um tamanho total de 1.000 CFP, dos quais 100 CFP são interfaces que precisam ser reescritas (TD). O custo por CFP ou o custo por FP para substituir ou reescrever o atalho geralmente pode ser determinado prontamente usando dados de referência. O custo do reparo pode ser $800 – $1500 por CFP. Usar uma abordagem de dimensionamento universal significa que ela pode ser aplicada em TD em código, designs, arquitetura e até mesmo requisitos. É muito importante considerar também o custo da migração do estado anterior e posterior, bem como quaisquer impactos não técnicos, tais como mudanças nas pessoas e nos processos.

Impacto nos negócios

Ao determinar o custo geral do TD, você precisa considerar tanto o valor que ele está impactando o seu negócio quanto o custo para repará-lo. A abordagem caso a caso da avaliação de impacto é adequada. E isso geralmente só pode ser determinado pela colaboração do pessoal técnico e de negócios para responder “até que ponto os atalhos técnicos estão impedindo a empresa de atingir seus objetivos”

Expondo Dívida Técnica

Expor o DT é útil porque pode ajudar a fornecer informações antecipadas para decisões estratégicas sobre sistemas de software. Por exemplo, um sistema sobrecarregado com TD pode ser candidato a substituição antecipada. Considerando que outro software com TD limitado pode ser mais adequado para prolongar sua vida útil.

Identificando dívidas técnicas em sua organização

Se um aplicativo de software é constantemente descrito como inflexível devido à maneira como armazena/manipula/estrutura dados, então isso pode muito bem ser o TD que está impedindo você. Em outras palavras, atalhos técnicos ou decisões de design inadequadas que nunca mudaram para atender às necessidades dos negócios.

Se um projeto para implementar algumas alterações novas ou no software passar por longos períodos de correção de bugs ou refatoração, isso pode ser causado por trabalho com requisitos ruins que gerou dívida técnica.

Evitando dívida técnica

Esta é a abordagem mais prudente. É a noção de que é mais barato desenvolver o software certo na primeira vez. No entanto, respeitando a definição original do termo de Ward Cunningham, isso não é possível. Se a necessidade (estratégica) e o uso do software não fossem conhecidos quando o código foi escrito pela primeira vez, então algum DT seria inevitável. No entanto, todos os esforços devem ser feitos para manter este retrabalho ao mínimo. A abordagem para fazer isso é permitir tempo e recursos suficientes para executar adequadamente os requisitos, a arquitetura e o trabalho de design antes do início da codificação. Isto deve expor as incógnitas conhecíveis para que a criação e eliminação de DT sejam evitadas.

Reduzindo a dívida técnica

Existem duas abordagens gerais para reduzir o TD:

1. Faça a reescrita detalhada para eliminar o atalho ou defeitos problemáticos.

2. Supere a dívida. Faça uma substituição no atacado do TD por um código reutilizável adequado. (“Leapfrog the Legacy”, a ideia de ultrapassar o legado não é nova, embora eu tenha cunhado esta frase porque acho que ajuda pessoas não técnicas a entender o caso de algumas decisões técnicas envolvidas.)