Até hoje eu reflito e não me conformo como não pude identificar que aquele projeto, lá no passado, estava claramente destinado ao fracasso.
Eu era o mais novo programador júnior a ingressar em uma equipe de desenvolvedores, analistas e DBAs engravatados que trabalhavam com tecnologias de no mínimo 5 anos atrás: um típico ambiente corporativo.
Trabalhávamos com servidores, ferramentas e técnicas que estavam no auge… da geração passada. Engessados não pela falta de recursos, que era abundante, nos afogávamos em processos burocráticos que impediam os profissionais de inovar.
Nossa criatividade era direcionada para o maior desafio técnico na nossa rotina: vencer o proxy corporativo que nos impedia de navegar livremente na internet. E nós éramos muito bons nisso. Tão bons que se essa habilidade não beirasse o ilegal, eu colocaria em destaque no meu currículo.
O objetivo a longo prazo era totalmente vago: migrar de uma linguagem de programação para outra. Não haviam requisitos claros pra essa migração, e o código estava uma completa porcaria.
Eis o que geralmente acontece quando você migra um projeto ruim de uma tecnologia pra outra sem um conjunto de requisitos bem definido: você inevitavelmente repetirá boa parte da arquitetura inapropriada e desajeitada do projeto original.
Arquitetura de código não é um negócio genérico. Você tem que conhecer a linguagem para qual arquiteta, e isso pode parecer incrivelmente óbvio, mas nosso gerente talvez não compartilhasse do mesmo esclarecimento: ele colocou analistas de uma liguagem de programação para coordenar programadores que trabalhavam com outra.
O projeto atrasou pelo menos uns 4 anos. Não sei ao certo, porque quando entrei ele já estava atrasado, e quando saí ele ainda não estava concluído. Desse meu tempo nesse e outros projetos desse emprego específico eu trouxe comigo muitas histórias que compartilharei com vocês aqui.
