A tecnologia muda todo dia, sua empresa deveria tentar acompanhar?

Na verdade, não. A menos que o próprio negócio gere essa necessidade de mudança.

É um erro que muitos (eu inclusive) cometem. Sai uma nova tecnologia e nosso software precisa ser reescrito usando ela. Mas que vantagem isso traz para o nosso negócio e para os nossos usuários finais? Na maioria dos casos, nenhuma.

Em vez de gastar tempo migrando para tecnologias mais novas ou atualizando e retestando depois de cada release menor das suas 250 dependências, esse tempo poderia ser investido em desenvolver e entregar novas funcionalidades para os seus usuários finais. Sério, ninguém está nem aí se você está rodando a última versão do Angular se faltam funcionalidades que seus concorrentes têm.

Ok, você pode dizer, mas e daqui a 3 anos quando for necessário atualizar e você estiver 10 versões major atrás e com toneladas de código “legacy”?

Primeiro, tenha orgulho do que você conquistou. O fato de você ter priorizado seus recursos corretamente significa que seu negócio agora está impulsionando a mudança e exige que você atualize. Sem essa priorização, seu negócio talvez nunca tivesse decolado, e você continuaria trabalhando no escuro, atualizando entre versões do Angular sem ninguém realmente usando seu software.

Segundo, não tente reescrever todo o seu software. Isso é especialmente verdadeiro em aplicações web. No começo, reescreva apenas os módulos para os quais a atualização era necessária. Continue com novos módulos ou funcionalidades que estiver desenvolvendo e, à medida que mudanças maiores apareçam em outros módulos, decida se vale a pena reescrever e, em caso afirmativo, faça-o.

Se está funcionando, não mexa

Toda mudança que você faz introduz risco, então com toda atualização será necessário retestar seu software. Como alternativa, você pode simplesmente soltar ele no mundo e ficar atento a incêndios; isso também funciona, até certo ponto, e depende muito da situação. Você pode fazer isso para o seu próprio produto, porque se algo acontecer e você perder dinheiro, é a sua culpa, é o seu dinheiro. Mas e quando você faz essa mudança para um cliente, achando que está fazendo bem, mas o cliente não pediu e você não se preocupou em avisá-lo, e acaba introduzindo um bug que faz o cliente perder dinheiro? Exatamente. Você assumiu um risco por algo que o seu cliente não consegue quantificar e estourou na sua cara.

Justificando a mudança

A mudança pode ser justificada. Só certifique-se de não estar mentindo para si mesmo (ou para o cliente, se estiver trabalhando para outra pessoa) em nome do brinquedo novo. Brinquedos vão e vêm; quebram, são jogados fora e você compra brinquedos novos. Pense em termos de ferramentas, em produtividade, performance, segurança. “Reduzir risco” é genérico demais. Tenha argumentos e números reais para sustentar uma decisão dessas.