Síndrome do N-ésimo Sistema

A Guta escreveu sobre o Fenômeno da Segunda Vez, pelo qual um software escrito pela segunda vez é muito melhor do que a versão original, e eu descaradamente me ofereci pra escrever sobre um fenômeno com raízes similares, mas com efeito negativo.

Quando minha equipe estava começando a reescrever um sistema grande para torná-lo mais fácil de gerenciar e estender, conversávamos empolgadamente sobre nossas ideias para a nova arquitetura. Fomos interrompidos por um membro de outra equipe: "vocês não têm medo de cair na Síndrome do Segundo Sistema"?

Fred Brooks define a Síndrome do Segundo Sistema assim:

[Um arquiteto que desenha seu primeiro sistema] sabe que não sabe o que está fazendo, e então o faz com cuidado e de forma reprimida. Enquanto desenha seu primeiro trabalho, ocorre-lhe um enfeite após o outro. Ele vai guardando esses enfeites para usá-los "da próxima vez". Cedo ou tarde o primeiro sistema é terminado, e o arquiteto [...] está pronto para construir um segundo. Esse segundo sistema é o mais perigoso que um arquiteto desenha. [...] A tendência geral é exagerar no projeto, usando todos os enfeites e ideias que foram cuidadosamente descartados da primeira vez.

Embora não tenhamos caído na Síndrome do Segundo Sistema, acabamos caindo numa versão generalizada do problema que eu chamo de Síndrome do N-ésimo Sistema (N > 2). O desenvolvedor que sofreu com o (N-1)-ésimo projeto usa sua experiência recente para dizer: "Não vou cometer nenhum dos erros daquele outro projeto. Agora tudo vai ser diferente".

Nessa síndrome, os ex-membros de um projeto conhecem todos os seus defeitos e pontos de falha. Sabem como o contato de diferentes pessoas e novos requisitos com o código afeta sua qualidade. E decidem, "na-na-não; dessa vez nós vamos fazer tudo direitinho". No processo de tentar fazer tudo direitinho, acaba-se introduzindo uma hipertrofia de inovações, verificações e restrições que permitem que a complexidade do sistema "caiba" na cabeça de quem o projeta. Os ex-sofredores com aquele código ruim e processo esquisito do (N-1)-ésimo sistema tentam melhorar seu ambiente de trabalho e criam novas regras e restrições também no N-ésimo processo de desenvolvimento para melhorar sua vida.

Na prática, como diz meu gerente favorito, isso significa que os erros cometidos no N-ésimo projeto são totalmente novos. As restrições no processo cujo objetivo era melhorar a vida de todos acabam criando grilhões que tornam os desenvolvedores insatisfeitos e menos produtivos. A nova arquitetura faz com que a qualidade do código comece bem, mas logo chegam aqueles novos requisitos que vão transgredir essa arquitetura só um pouquinho, mas cujo custo-benefício é obviamente vantajoso para o usuário.

Com o tempo, o lado "custo" da balança de vários pequenos requisitos vai se somando e ficando mais pesado, e o N-ésimo sistema vira um monstro pior do que o anterior - ele não só contém tantas transgressões à arquitetura original quanto o projeto N-1, mas a nova arquitetura e o novo processo de desenvolvimento são tão restritivos e complexos que o código e o ambiente de trabalho ficam piores do que os do sistema anterior.