Culpando os males de hoje sobre a dívida técnica de ontem

A dívida técnica é como a dívida financeira. Você assume isso (espero) estrategicamente no desenvolvimento de um programa com a intenção de que ele seja pago no futuro. Às vezes, as pessoas tomam decisões técnicas ruins sobre a dívida (como a execução de um cartão de crédito), mas às vezes uma certa dívida técnica é apenas normal. Decidir não dedicar o tempo para fazer algo da maneira "certa" hoje com a suposição de que ele precisará ser mudado no futuro é completamente normal e deve ser antecipado. É claro que há uma linha tênue, mas pensar que você fará da maneira certa a primeira vez que pode causar seu próprio conjunto de problemas (paralisia da análise).

Em resumo, qualquer projeto não-trivial que durar mais do que um par de anos precisará dedicar algum novo tempo de desenvolvimento para pagar a dívida técnica. A coisa é, isso é verdade mesmo se você escrever seu aplicativo da maneira correta . Se você não está acumulando dívidas sobre dívidas, e a administração pode certamente entender isso se você apresentar dessa maneira.

Explique isso à gerência e, em vez de "culpar" a equipe anterior o tempo todo, você pode apresentar isso como "business as usual".

IMO você já está agindo da maneira correta: você não está sugerindo uma reescrita de base porque "o código antigo é uma merda", mas consertando uma coisa de cada vez.

Para evitar sentir que você está culpando a equipe antiga, imagine que eles provavelmente tiveram que produzir esse código sob grande pressão de tempo. Na época, a gerência provavelmente não entendia realmente que só porque o código "funciona mais ou menos" não significa que qualquer manutenção seja possível sem muita dor e retrabalho.

Aprecie a antiga equipe por conseguir fazer um produto que realmente ofereça algum valor comercial - ele não estaria mais em uso se não o fizesse. Você pode se surpreender com a frequência com que um projeto falha em fornecer valor comercial, mesmo que seja bem escrito.

Quando solicitado a comentar sobre o estado atual de um produto problemático, eu sempre recito, "é o que é", e então começo a falar sobre os planos para melhorá-lo.

Você não conhece todos os fatores que influenciaram a decisão que criou esse problema - talvez eles fossem até razoáveis na época. Tudo o que você pode fazer é seguir em frente e melhorar as coisas amanhã. E parece que você está fazendo um bom trabalho - você tem a atitude certa para essa situação.

Concentre-se apenas em relatar fatos quando solicitado. Você não precisa adicionar narrativa ou comentário; basta dizer "o sistema falha no caso X" ou "os relatórios estão incorretos para o caso Y." Em seguida, adicione rapidamente como você planeja melhorar a situação atual.