O custo da programação tática

Até recentemente, eu não sabia que uma característica que eu ostentava há anos com orgulho não era algo que eu deveria me orgulhar. Com uma carreira relativamente extensa, boa parte das empresas por onde passei viam com bons olhos programadores que resolviam os problemas da forma mais rápida possível. Fazendo isso obtive sucessivas promoções, afinal, velocidade significa menos custo para a empresa, certo? Errado!

Lendo um “livrinho” bem popular aqui na ilegra chamado A Philosophy of Software Design, de John K. Ousterhout (caso ainda não tenha lido, leia, vale muito a pena!), me deparei com o termo programação tática e, na sequência, a definição de programador tático, com a qual me identifiquei. Logo a seguir me veio em mente o Capitão Nascimento soltando sua célebre frase “Boooooooa, zero meia!” no momento de um commit – mas não, não tem nenhuma relação com isso.

Programador tático é aquele focado em produzir código rodando o mais rápido possível, sem se importar tanto com o design no longo prazo. O efeito colateral dessa abordagem é o acúmulo de pequenas complexidades no código, uma vez que adicionar apenas um pouco de complexidade é aceitável para se entregar uma tarefa no prazo. Todavia, se o projeto conta com um time de dez desenvolvedores fazendo o mesmo, a complexidade gerada se torna extremamente alta.

O primeiro caso que me recordei foi de uma empresa da área de saúde na qual trabalhei por quatro anos, sendo três como programador e um como gestor. Essa empresa foi pioneira na área de atuação aqui no Brasil e o clima entre as áreas de negócio e TI era o mais hostil que eu havia visto até então. Nela, TI era vista como um custo, e não como uma área estratégica; sempre que algo atrasava, por qualquer motivo que fosse, a culpa era da TI!

Vale ressaltar que o produto em si era composto por dois componentes: uma área de atendimento semelhante a um call-center e um software de gestão capaz de trafegar o beneficiário (a pessoa que receberia o atendimento por intermédio da empresa em questão) e os profissionais do atendimento, que eram enfermeiros, médicos e especialistas. A parte de software do produto possuía algo em torno de dez anos e havia sido implementado com uma arquitetura monolítica quando a empresa foi comprada por uma multinacional gigante da área de telefonia, que adquiriu cinquenta por cento do controle para, três anos mais tarde, concluir a compra. Nesse momento, esse software garantia o atendimento a aproximadamente duzentas e vinte mil pessoas sendo operado por duzentos usuários.

No momento da compra, foi feito um due-diligence que se focou na parte do business, finanças, marketing e até TI. Porém, nenhum teste de carga ou stress foi realizado antes do contrato ser assinado. No primeiro dia de operação sob a nova gestão, o responsável pela transição decidiu iniciar os testes com um milhão de beneficiários, pois eles já possuíam setenta e um milhões para incluir no sistema. Lembro como se fosse hoje a reação dos desenvolvedores na sala de reunião – todos se entreolharam e baixaram as cabeças, pois sabiam que era simplesmente impossível. O sistema já estava em um ponto onde qualquer alteração levava mais tempo do que o necessário pela complexidade acumulada ao longo dos anos e também não era escalável desta forma.

Em resumo, após um ano sob nova gestão eu saí da empresa, pois não fazia mais sentido ser um gestor se não podia tomar as decisões que precisavam ser tomadas (apenas um louco aceitaria reescrever o sistema do zero). A empresa passou mais três anos se equilibrando pois, sem conseguir escalar, o negócio não era tão rentável assim e, quatro anos mais tarde, a multinacional decidiu vendê-la. Claro que existem questões políticas na escolha e a multinacional poderia ter reescrito o sistema se assim o quisesse, teria sido mais rápido do que não fazê-lo, mas veja o tamanho do estrago causado! A cultura de meter o pé na porta para resolver os problemas de forma rápida causou um acúmulo tamanho que o sistema ficou travado, pouco pode ser feito à partir disso. Não tive acesso aos números mas estou certo de que essa brincadeira custou uns bons milhões e bastante tempo, além de arranhar o nome da companhia e abrir o mercado para concorrentes.

Entre as lições que aprendi por lá, a maior foi questionar se os requisitos de negócio estão claros o suficiente para se optar pelo design a ser seguido e pelo trade-off que custará. Lembre-se sempre que as decisões que tomamos ao escrever um software envolvem muito mais do que apenas “manter um emprego”.