Existe um tipo muito específico de mentira em tecnologia que quase nunca nasce de maldade. Ela nasce de cansaço, prazo curto e um otimismo irresponsável que aparece mais ou menos às 18h40 de uma quinta-feira. A frase vem em versões diferentes, mas a essência é sempre a mesma: depois eu arrumo isso.
O problema é que esse “depois” em TI tem comportamento próprio. Às vezes chega amanhã. Às vezes chega no próximo sprint. Às vezes chega seis meses depois em forma de incidente, retrabalho ou cara de sofrimento de quem abriu o arquivo pela primeira vez desde a promessa original.
A verdade é que toda equipe convive com pequenas pendências empurradas para frente. Nem sempre isso é erro. Às vezes é só trade-off honesto. O lado engraçado é que existe um repertório quase universal das coisas que desenvolvedor vive jurando que vai consertar em breve. E algumas delas realmente entram para o folclore interno da firma.
1. “Depois eu limpo esse código”
Clássico absoluto. O código funciona, a entrega precisava sair, a lógica ficou meio feia, os nomes estão estranhos, tem repetição em três lugares e um bloco de condição que parece escrito durante um pequeno colapso emocional. Mas tudo bem. Depois limpa.
Às vezes limpa mesmo. Só que o mais comum é o código seguir vivendo exatamente como está, agora cercado por novas camadas de remendo que respeitam o caos original como patrimônio histórico.
2. “Depois eu escrevo os testes”
Essa merece respeito porque costuma vir acompanhada de boa intenção genuína. A pessoa sabe que deveria testar. Ela acredita nos testes. Ela defende testes em reunião. Só que, naquele momento, a entrega precisava ir.
Quando o depois não chega, a feature entra oficialmente para a categoria “todo mundo tem medo de mexer, mas segue em produção por intervenção divina”.
3. “Depois eu refatoro com calma”
Esse é primo do primeiro item, mas com autoestima um pouco maior. Aqui o desenvolvedor já enxerga claramente o desenho melhor. Ele quase vê a arquitetura limpa na cabeça. Falta apenas uma janela de tranquilidade que, claro, nunca coincide com a realidade da operação.
Resultado: a refatoração vira lenda urbana. Sempre mencionada, raramente vista.
4. “Depois eu explico isso no README”
O projeto tem setup específico, variável de ambiente escondida, uma etapa de build que só funciona se você souber o truque e pelo menos duas decisões estranhas que exigem contexto histórico. Nada disso está documentado. Mas vai ficar. Depois.
Meses mais tarde, o README continua abrindo com um título, uma frase vaga e silêncio institucional.
5. “Depois eu removo esse workaround”
Toda equipe tem pelo menos um workaround que nasceu como medida provisória e envelheceu até virar parte da infraestrutura emocional da aplicação. No começo todo mundo sabia que era temporário. Com o tempo, ninguém mais lembra exatamente por que ele existe, mas todo mundo teme o que pode acontecer se alguém apagar.
É quase um objeto religioso.
6. “Depois eu organizo essas configs”
Variável espalhada, arquivo duplicado, segredo em lugar esquisito, nome inconsistente, ambiente que funciona só porque já está rodando faz tempo. O plano de organizar existe. Só não venceu ainda a pilha de urgências que se considera mais importante do que entender a própria configuração do sistema.
Até o dia em que alguma mudança quebra tudo e a empresa descobre que o mapa do tesouro nunca foi desenhado.
7. “Depois eu atualizo essa dependência”
Esse depois é traiçoeiro porque parece pequeno. É só uma lib. Só um pacote. Só um aviso de versão. Só um patch. Aí o tempo passa, a defasagem cresce e o update simples vira ritual de risco, com changelog assustador, comportamento alterado e sensação de que o sistema foi construído sobre um piso que envelheceu mal.
Foi só adiando até deixar de ser só isso.
8. “Depois eu quebro essa função em partes menores”
A função já passou de razoável faz tempo. Tem condição dentro de condição, retorno antecipado, comentário explicando o inexplicável e uma estrutura que parece ter evoluído por camadas geológicas. Mesmo assim, ela continua firme porque ninguém quer ser a pessoa que vai mexer ali sem cobertura suficiente.
Então ela segue crescendo. Não em dignidade, mas em linhas.
9. “Depois eu vejo por que isso funciona”
Essa talvez seja a mais sincera de todas. Alguma coisa foi ajustada, o erro sumiu e a aplicação voltou a respirar. Não houve compreensão completa, apenas sobrevivência bem-sucedida. O desenvolvedor promete voltar com mais calma para entender a causa real.
Em muitos casos, nunca volta. O sistema entra naquele acordo silencioso em que todo mundo aceita o funcionamento desde que ninguém faça perguntas demais.
O engraçado é que todo mundo ri porque todo mundo reconhece
A graça desse repertório vem do reconhecimento imediato. Toda pessoa de tecnologia já falou uma dessas frases, ouviu alguém falar ou herdou o resultado delas. É o lado humano da dívida técnica: uma mistura de pressão real, pragmatismo, sobrevivência e autoengano moderado.
Também vale dizer que nem toda promessa adiada é irresponsabilidade. Trabalho técnico envolve trade-off o tempo inteiro. O problema começa quando o “depois” vira modelo operacional permanente. Aí o acúmulo deixa de ser detalhe engraçado e vira custo previsível.
Mesmo assim, como retrato da vida em TI, essas frases têm um charme quase afetivo. Elas lembram que boa parte do software do mundo não foi construída por seres frios e perfeitos. Foi construída por gente tentando entregar, priorizar, apagar incêndio e voltar mais tarde com a dignidade possível.
Nem sempre volta. Mas a intenção, em algum momento, foi bonita.
Fontes
- ProgrammerHumor: https://programmerhumor.io/memes/technical-debt
- Reddit r/ProgrammerHumor: https://www.reddit.com/r/ProgrammerHumor/comments/1f4t0ya/imightbebadbutiamperfectlygoodatit/
