La perfección no es sobreingeniería
La perfección en la ingeniería de software es un terreno disputado: algunos sostienen que, con requisitos claros, existe una solución “perfecta”, mientras que otros dicen que las restricciones del mundo real, los objetivos cambiantes y los factores humanos hacen que esa noción sea irrealista o incluso perjudicial. Los comentaristas contraponen la calidad técnica genuina y la simplicidad elegante con la sobreingeniería —como arquitecturas de microservicios innecesarias o pruebas excesivas— y subrayan que los requisitos poco claros o cambiantes son una fuente principal de sistemas hinchados. Muchos abogan por una vía intermedia pragmática: aspirar a alta calidad donde importa, aceptar lagunas y casos extremos documentados, y reconocer que los plazos, los presupuestos y el cambio futuro son también restricciones que moldean lo que debería significar “suficientemente bueno”.
Qué significa “sobreingeniería”
- Se ofrecieron varias definiciones:
- Resolver el problema equivocado u optimizar para restricciones que en realidad no tienes.
- Añadir complejidad innecesaria en comparación con el beneficio obtenido (p. ej., muchos microservicios para bases de usuarios diminutas).
- Sobredimensionado frente a sobreingenierizado: “demasiado fuerte” vs “demasiado complejo para los requisitos”.
- Algunos señalan que el término se usa mal para significar “no entiendo esto” o para denigrar abstracciones elegantes.
Perfección vs “suficientemente bueno”
- Muchos critican “no dejes que lo perfecto sea enemigo de lo bueno” como un cliché que a menudo se usa para justificar la entrega de sistemas frágiles y de baja calidad.
- Otros lo defienden como una forma de evitar la parálisis por el pulido interminable o por atender casos límite ultrarraros.
- Algunos argumentan que la “perfección” en ingeniería debería significar “corrección frente a restricciones bien definidas”, no perfeccionismo neurótico.
- Otros dicen que la perfección verdadera no existe; la mayoría de los problemas tienen múltiples soluciones llenas de compensaciones, no un único óptimo.
Requisitos, restricciones y realidad cambiante
- Tema fuerte: la mayor parte de la sobreingeniería proviene de requisitos pobres, ausentes o en cambio constante.
- Quienes critican la tesis del artículo dicen:
- Las restricciones son flexibles, se compensan entre sí y cambian con el tiempo.
- Casi nunca tienes “todas las restricciones sobre la mesa”, así que afirmar una solución única “perfecta” es irrealista.
- Los enfoques iterativos (construir–observar–refinar) se ven como más honestos dadas las incógnitas desconocidas.
Elecciones de arquitectura y microservicios
- Los microservicios se citan repetidamente como ejemplo clásico de sobreingeniería cuando se adoptan por escalabilidad, alta disponibilidad o independencia de equipos que no existen.
- Algunos sostienen que los microservicios resuelven principalmente la escalabilidad organizativa (Ley de Conway); reproducir eso en equipos pequeños es “construir una economía interna para un blog personal”.
Casos extremos, fiabilidad y compensaciones de guardia
- Debate sobre ignorar escenarios raros:
- Gerentes/producto a menudo empujan por soluciones del percentil 90.
- Los ingenieros responsables de incidentes a las 2 de la mañana resienten que les digan que ignoren fallos raros pero disruptivos.
- Compromiso sugerido: documentar explícitamente los casos no soportados, registrarlos, y evitar bloquear la evolución futura.
Pruebas, calidad y costo-beneficio
- La sobreingeniería puede aparecer como cobertura excesiva de pruebas unitarias o QA pesado que ralentiza el trabajo de nuevas funciones sin mejorar la fiabilidad en el mundo real.
- Énfasis en pensar en costo-beneficio/FMEA: invertir mucho donde la severidad y la probabilidad lo justifiquen, y aceptar lagunas en otros lugares.
El perfeccionismo en la práctica
- Algunos ven como perfeccionismo extendido los proyectos secundarios crónicos que nunca se publican y las reescrituras interminables.
- Otros dicen que, en entornos profesionales, el verdadero problema son los sistemas sobrepocoingenierizados y llenos de spaghetti, no los perfeccionistas míticos.