O software está no ar, tem clientes (muitos!) e não existe espaço para nada mais além de manter o software no ar, enquanto os novos requisitos de negócio vão acontecendo no código. Quais as consequências dessa visão?

Code base que só cresce

Se o número de linhas de código só aumenta e se o crescimento é da taxa de 100 linhas por dia (o que é pouco para uma grande empresa, concorda?). Em um ano a empresa terá que lidar com um software de 36 mil linhas. Se isso já não fosse problema suficiente, ainda podemos somar outras características.

Software se torna cada vez mais complexo

Número de linhas não é exatamente uma medida de aumento de complexidade. A medida final da complexidade é a dificuldade de ler e entender o software sem o auxílio de muletas e esse cenário se torna mais distante quando o design não acompanha o crescimento do software (reflexo de novos requisitos de negócio). Mais ou menos como se uma cigarra que cresce não trocasse de exoesqueleto e ele fosse se tornando contenção ao invés de suporte de vida.

Códigos que tratam o efeito é ignoram a causa

O codebase tem cada vez mais linhas, ele é cada vez mais complexo e a empresa, como medida de seu sucesso, realiza cada vez mais e mais rápido. Não há tempo para perder e isso aponta para situações onde os bugs “são corrigidos” nas camadas acima de onde eles realmente existem. Problemas com um tipo errado de informação se torna um “if no controller” e uma regra de negócio que entrega o valor com um medida fixa de distorção/erro se torna “adicionar 10% direto ao resultado da regra e está pronto”.

Tempo de desenvolvimento maior

Adicionar um recurso simples é procurar a ponta em um novelo de lã depois do gato brincar com ele. Nada mais é simples como parece. Surgem as discussões entre os times de negócio e o técnico. A comunicação não funciona por que o software é surreal, mas ninguém aceita o fato de que é necessário um refactoring do software do seu design, por que isso “não adiciona valor ao negócio”. Como não?!

Arquitetura rígida

Até que em dado momento nada mais é aceitável. O tempo que demora para adicionar algo simples não é aceitável. Ficar sem a funcionalidade no tempo necessário não é aceitável. Um refactoring não é aceitável. Dead lock!

Deixar os débitos técnicos se acumularem é o caminho para a multiplicação dos gremlins. Ter isso em mente é importante tanto para o cara de negócio, quanto para o desenvolvedor. Enquanto desenvolvedor, você deve fazer o export de que débitos técnicos estão sendo criados e o impacto disso no futuro da aplicação. Deve deixar claro que argumentar que isso não é importante é como dizer que o futuro da empresa não é importante.

Se você esquecer disso: