Perfeição não é superengenharia
A perfeição em engenharia de software é um terreno contestado: alguns argumentam que, com requisitos claros, existe uma solução “perfeita”, enquanto outros dizem que restrições do mundo real, objetivos em mudança e fatores humanos tornam essa noção irrealista ou até prejudicial. Os comentaristas contrastam qualidade técnica genuína e simplicidade elegante com superengenharia — como arquiteturas de microsserviços desnecessárias ou testes em excesso — e destacam que requisitos obscuros ou em evolução são uma das principais causas de sistemas inchados. Muitos defendem uma via prática do meio: buscar alta qualidade onde importa, aceitar lacunas e casos extremos documentados e reconhecer que prazos, orçamentos e mudanças futuras também são restrições que moldam o que “bom o bastante” deve significar.
O que “superengenharia” significa
- Várias definições foram apresentadas:
- Resolver o problema errado ou otimizar para restrições que você não tem de fato.
- Adicionar complexidade desnecessária em relação ao benefício (por exemplo, muitos microsserviços para bases de usuários minúsculas).
- Superconstruído vs superengenheirado: “forte demais” vs “complexo demais para os requisitos.”
- Alguns observam que o termo é usado incorretamente para significar “eu não entendo isso” ou para menosprezar abstrações elegantes.
Perfeição vs “bom o bastante”
- Muitos criticam “não deixe o perfeito ser inimigo do bom” como um clichê frequentemente usado para justificar o envio de sistemas frágeis e de baixa qualidade.
- Outros o defendem como uma forma de evitar a paralisia causada por polimento interminável ou pelo tratamento de casos extremos ultra-raros.
- Alguns argumentam que “perfeição” em engenharia deveria significar “correção diante de restrições bem definidas”, e não perfeccionismo neurótico.
- Outros dizem que a verdadeira perfeição não existe; a maioria dos problemas tem várias soluções cheias de trade-offs, e não um único ótimo.
Requisitos, restrições e realidade em mudança
- Um tema forte: a maior parte da superengenharia vem de requisitos ruins, ausentes ou em constante mudança.
- Críticos da tese do artigo dizem:
- As restrições são flexíveis, fazem trade-off entre si e mudam ao longo do tempo.
- Quase nunca se tem “todas as restrições sobre a mesa”, então alegar uma solução única “perfeita” é irrealista.
- Abordagens iterativas (construir–observar–refinar) são vistas como mais honestas diante de desconhecidos desconhecidos.
Escolhas de arquitetura e microsserviços
- Microsserviços são citados repetidamente como superengenharia clássica quando adotados para escala, alta disponibilidade ou independência de equipes que não existem.
- Alguns argumentam que microsserviços resolvem principalmente o escalonamento organizacional (Lei de Conway); reproduzir isso em equipes pequenas é “construir uma economia interna para um blog pessoal”.
Casos extremos, confiabilidade e trade-offs de plantão
- Debate sobre ignorar cenários raros:
- Gestores/produto muitas vezes pressionam por soluções no percentil 90.
- Engenheiros responsáveis por incidentes às 2h da manhã ressentem-se de receber ordens para ignorar falhas raras, mas disruptivas.
- Compromisso sugerido: documentar explicitamente os casos não suportados, registrá-los em logs e evitar bloquear a evolução futura.
Testes, qualidade e custo-benefício
- A superengenharia pode aparecer como cobertura excessiva de testes unitários ou QA pesada que desacelera o trabalho em funcionalidades sem melhorar a confiabilidade no mundo real.
- Ênfase no raciocínio de custo-benefício/FMEA: investir fortemente onde a severidade e a probabilidade justificam, aceitar lacunas no restante.
Perfeccionismo na prática
- Alguns veem projetos paralelos crônicos que nunca são entregues e rewrites intermináveis como perfeccionismo disseminado.
- Outros dizem que, em ambientes profissionais, o problema real é a existência de sistemas subengenheirados e cheios de gambiarras, não perfeccionistas míticos.