Perfeição não é over-engineering
A distinção entre perfeição e excesso
A ideia de que uma solução perfeita seria necessariamente um caso de excesso de engenharia confunde dois problemas diferentes. O excesso de engenharia não é cuidar demais da qualidade nem tornar algo bom demais: é resolver o problema errado. Em geral, isso acontece com boas intenções, mas produz uma acumulação de complexidade incidental.
Uma solução perfeita pode existir quando os requisitos são claros. Se todas as restrições relevantes estiverem definidas - necessidades dos usuários, desempenho, familiaridade da equipe, custos e outras condições do caso - o espaço de alternativas pode se estreitar até restar uma única solução possível. Ela é perfeita não por ser universalmente superior, mas por ser a única que atende àquele conjunto de exigências. Com restrições diferentes, outra solução pode ser a perfeita para o mesmo tipo de problema.
Por isso, escolhas técnicas não devem ser avaliadas isoladamente. Em um projeto novo, por exemplo, a decisão entre diferentes linguagens, ferramentas e modelos de hospedagem depende dos requisitos. Python pode ser adequado em um cenário, enquanto outra opção pode fazer mais sentido para quem não conhece a linguagem ou precisa priorizar desempenho. Da mesma forma, Django e Flask podem produzir resultados semelhantes em uma aplicação web, mas representam filosofias diferentes; requisitos mais precisos ajudam a determinar qual atende melhor ao caso.
Sistemas também são produtos
O problema dos requisitos não é apenas técnico. Bibliotecas, APIs e ferramentas internas também são produtos: têm usuários e precisam atender a necessidades concretas. Antes de decidir oferecer um serviço, uma API ou uma biblioteca, é preciso entender qual formato resolve melhor o problema. A forma da solução se torna mais evidente quando o sistema é tratado como um produto e seus requisitos são definidos com honestidade.
Um indício claro de excesso de engenharia aparece quando ninguém consegue explicar satisfatoriamente por que o sistema foi construído daquela maneira. O exemplo apresentado é o de uma equipe de três pessoas responsável por cinco microsserviços que compartilham dados. A arquitetura pode parecer justificável em abstrato, mas sua avaliação depende do problema que se pretendia resolver.
A separação pode substituir referências fortes no banco de dados, como chaves estrangeiras, por identificadores soltos. Com isso, a integridade dos dados se perde: um serviço pode excluir um registro sem que outro saiba, deixando uma referência inválida que só será descoberta depois. Se todos os serviços pertencem ao mesmo domínio, a comunicação e a operação distribuídas podem acrescentar cerimônia, inconsistência e custos operacionais sem necessidade.
A equipe talvez tenha obtido implantações independentes, mas isso só seria uma vantagem relevante se escala ou divisão de responsabilidades fossem problemas reais. Nesse caso, uma equipe pequena e um único domínio podem ter levado à solução de problemas que não estavam presentes, em troca de novos problemas que não existiriam em uma arquitetura mais simples. A marca do excesso não é falta de elegância ou de cuidado: é resolver problemas que nunca foram necessários.
O ponto de partida são os requisitos
A conclusão é que o excesso de engenharia resulta de uma falha na coleta de requisitos. A equipe pode executar com rigor o trabalho de engenharia e ainda assim construir a resposta errada se tiver definido mal as necessidades. A perfeição não é o inimigo; requisitos ambíguos são. Quando as restrições certas são reunidas e esclarecidas, a solução perfeita deixa de ser uma fantasia e passa a ser a alternativa que melhor - ou unicamente - se encaixa no problema real.