Todo engenheiro de software, em algum momento da carreira, atravessa a fase da “reinvenção da roda”. É notório que nenhum desses profissionais iria escrever um sistema de banco de dados do início se esse não for verdadeiramente o core da empresa. Então, eles também não deveriam escrever um sistema de feature flags ou um de configuração de kubernetes. Embora pareçam mais simples, geram um custo alto de manutenção no longo prazo. O indicado, nesse caso, é optar por uma empresa cujo core business seja “codar” esse tipo de sistemas.
E um dos principais fatores que vai determinar isso é o custo da manutenção — o vilão silencioso de toda operação de software de longo prazo. Estudos, como um publicado na revista científica Acta Informatica Medica e outro no Journal of Computer and Communications, apontam que a manutenção de software pode consumir de 70% a 90% do custo total de um sistema ao longo do tempo. Isso porque cada linha de código que você escreve hoje é uma linha de código que sua empresa vai pagar para manter em funcionamento indefinidamente.
A conta é simples: quanto mais código próprio em áreas que não são o core business, maior deverá ser o time de engenharia necessário apenas para manter o sistema de pé.
Por isso, na Unico, rede de validação de identidade, temos uma espécie de regra interna para evitar essa situação. Antes de escrever qualquer pedaço novo de código, a primeira pergunta que nós fazemos é: esse sistema está alinhado com a missão da empresa? Se a resposta for não, dificilmente o código será escrito dentro de casa.
Repare: não se trata de falta de skills. A questão aqui é estratégia. Capacidade nós temos e, justamente por ter um time capaz, fazemos escolhas conscientes sobre onde alocar esse esforço. Não vale a pena desperdiçar tempo nem talento reinventando o que já funciona bem no mercado.
Então, ninguém nunca escreveria seu próprio, adaptaria um PostgreSQL ou MySQL num infraestrutura de Cloud. Então por que alguém construiria seu próprio sistema de features flags? Na Unico confiamos no Launchdarkly. E continuous delivery? ArgoCD. Sistema de documentação? Confluence. Scanners de arquivos? SaaS especializados. Expressões regulares? Bibliotecas maduras. E por aí vai — a lista é bem longa.
Esses são os chamados “problemas horizontais”: desafios que, embora críticos para a operação, não diferenciam o produto no mercado. Resolver esses problemas internamente é, em geral, desperdício de energia criativa e recursos. Afinal, cada novo sistema é, potencialmente, uma startup interna que vai exigir investimento contínuo.
Diante disso, fica a questão: queremos construir mais startups de infraestrutura ou queremos fortalecer nosso produto de validação de identidade? Acredito que a maioria há de concordar que a melhor forma de gerar valor sustentável é concentrar talento e investimento naquilo que nos diferencia no mercado.
Isso não significa, evidentemente, que o caminho do “compre em vez de construir” seja isento de riscos. Toda dependência externa adiciona pontos de contato no código e na organização. E é aqui que muitos engenheiros sêniores demonstram maturidade: não se trata de demonizar dependências, mas de integrá-las com responsabilidade.
Na Unico, temos um Tech Advisor que costuma dizer que, enquanto os benefícios de adicionar uma dependência crescem de forma linear, os custos aumentam exponencialmente. Isso por conta do número de times e sistemas ligados a essa dependência. O risco é claro, um simples parser de PDF isolado em um microserviço é uma coisa. Introduzir uma nova linguagem de programação inteira na organização é outra bem diferente.
Por isso, o processo de decisão precisa ser rigoroso e avaliar a criticidade do problema, priorizar soluções nativas do provedor de nuvem já adotado, verificar se outras tribos já resolveram o problema internamente e ler a documentação com atenção. É necessário, sobretudo, optar por ferramentas populares e bem mantidas, mesmo que o custo seja maior.
Mais importante ainda é fugir da armadilha mental dos problemas hipotéticos. Aquelas perguntas que surgem na cabeça do engenheiro vez ou outra, como “e se no futuro precisarmos de X?” ou “e se uma aquisição trouxer um novo cenário?”. Nesses casos, o melhor antídoto para o medo do incerto continua sendo o velho mantra YAGNI (You Are Not Gonna Need It). Ou seja, resolva o problema que você tem hoje.
Se o problema do futuro aparecer, resolveremos com a mesma disciplina e pragmatismo que aplicamos hoje: com dados, contexto real e foco no que de fato move o negócio.
A maturidade técnica não é escrever mais código. É escrever apenas o que importa. É entender que cada linha a menos de código é um favor que você está fazendo para o seu “eu do futuro” — e para toda a empresa.
No final, é sobre alocar o talento certo, no problema certo. E não há talento mais valorizado hoje do que o engenheiro que sabe dizer com firmeza: aqui, não vamos escrever código.
*Por Bruno Fonseca, diretor sênior de engenharia da Unico.
