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

38

Um número surpreendente de problemas de qualidade, escalabilidade e carga está ocorrendo em um aplicativo atualmente suportado que eu não escrevi originalmente. Felizmente eu tenho novos projetos que venho fazendo desde o início para manter alguma aparência de minha sanidade.

A equipe original consistia em 20 desenvolvedores (a maioria deles com conjuntos de habilidades desatualizados), sem documentos de requisitos de negócios ou testadores de garantia de qualidade, e mal gerenciados desde o início de uma forma em cascata. Os primeiros dias de produção foram um pesadelo embaraçoso que envolvia remendar códigos frágeis processuais com consertos ainda mais frágeis. Os recursos foram adicionados mais tarde, que foram marcados em um datamodel que nunca foi feito para suportá-los e não é incomum ver o mesmo código duplicado 10 vezes e ver os recursos não serem fechados com segurança e consultas ORM que buscam dezenas de milhares de entidades jogar fora tudo menos um punhado.

Sou eu agora e sempre que surge um novo problema, eu reescrevo um módulo para melhorar os padrões e torná-lo MUITO mais estável, mas o Gerenciamento precisa de uma explicação adequada de por que tudo isso está acontecendo.

Eles parecem chocados e perplexos com a noção de que esta aplicação é de má qualidade e se afogando em dívidas técnicas. Felizmente eles entendem o conceito de dívida técnica e me apóiam em minha busca para erradicá-lo e eles me apoiam e apreciam muito, mas eu sinto como se eu simplesmente mantivesse culpando o time original (que todos deixaram) arruinar outro projeto em uma divisão diferente).

O ponto principal é que eu não quero ser "That Guy" que sempre reclama sobre os desenvolvedores do projeto antes dele. Eu já vi essa atitude antes de pessoas em minha carreira que eu pessoalmente sentia serem ignorantes e não considerando as circunstâncias e as influências de design que encorajavam as coisas a serem do jeito que eram.

Geralmente eu vejo essa atitude de culpar a equipe anterior pelo design e implementação pobres de desenvolvedores júnior idealistas que não tiveram as experiências de vida que os membros mais antigos tiveram e se beneficiaram.

Você acha que existe uma maneira melhor, talvez mais suave, de relatar esse tipo de problema para o gerenciamento sem ter que passar pela reputação da pessoa / equipe antes de você?

    
por maple_shaft 27.07.2011 / 15:40
fonte

3 respostas

46

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".

    
por 27.07.2011 / 16:21
fonte
23

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.

    
por 27.07.2011 / 15:56
fonte
7

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.

    
por 27.07.2011 / 17:26
fonte

Tags