🔓 Open Source
Cómo escribir código perfecto sin caer en sobreingeniería — la lección que todo dev debería aprender
—No busques la perfección, solo haz que funcione—.
Si eres desarrollador, has escuchado esta frase al menos cien veces. En reuniones de planning, en code reviews, en tweets de gurús tecnológicos. Se ha convertido en el mantra incuestionable de la industria, repetido como un rezo laico: la perfección es el enemigo de lo bueno.
¿Y si te dijera que esa frase está mal?
Un post publicado en var0.xyz explotó en Hacker News con 239 puntos y 102 comentarios en cuestión de horas. No hablaba de un nuevo framework ni de un bug crítico. Hablaba de algo más profundo: la industria confundió dos conceptos completamente distintos y esa confusión nos está costando caro a todos.
Vamos a desenredar el nudo.
El problema: le tenemos miedo a la palabra "perfecto"
En cualquier equipo de desarrollo, decir "quiero hacer esto bien" equivale a ponerse un blanco en la espalda. Automáticamente te etiquetan como el dev que va a sobreingenierizar el proyecto, retrasar el lanzamiento y complicar lo que debería ser simple.
Y es cierto: la sobreingeniería existe. Hemos visto proyectos de 5 microservicios mantenidos por 3 personas. Hemos visto abstracciones innecesarias que resuelven problemas que nadie tenía. Hemos visto equipos quemados por soluciones elegantemente incorrectas.
Pero hay una diferencia abismal entre hacer las cosas bien y resolver el problema equivocado. Y esa diferencia es exactamente lo que la industria ha borrado.
1. La sobreingeniería es resolver el problema equivocado
El autor del post viral lo define de manera brillante: sobreingeniería no es "preocuparse demasiado" ni "hacerlo demasiado bueno". Es resolver el problema equivocado.
Punto. No hay más vuelta.
Cuando un equipo de tres personas construye cinco microservicios interconectados, no están siendo "perfectos". Están resolviendo un problema de escalabilidad y ownership que no tienen. Y están pagando el precio: integridad de datos perdida, overhead operacional, un sistema que resuelve muchos problemas a medias y ninguno completamente.
Eso no es perfección. Eso es un error de requisitos.
Y aquí está la clave: cuidar los detalles, escribir código limpio, pensar en la arquitectura antes de codificar — eso no es sobreingeniería. Es profesionalismo.
2. La solución perfecta SÍ existe (con una condición)
Aquí viene la parte que contradice todo lo que te han enseñado: la solución perfecta sí existe. Pero con una gran condición: necesitas requisitos claros.
Cuando tienes todas las restricciones sobre la mesa, cuando entiendes el problema real de tus usuarios, cuando delimitas el alcance con precisión quirúrgica... ocurre algo mágico: solo queda una solución posible. Y esa solución, irónicamente, es la perfecta.
No es subjetiva. No es "cuestión de gustos". Es la única que encaja con las restricciones dadas.
Empiezas un proyecto nuevo. Todos los lenguajes, todas las herramientas, todos los modelos de hosting disponibles. Eliges serverless con Python. Excelente elección... para tus restricciones. Para otro equipo con otras restricciones, sería la peor decisión.
Mismas restricciones → misma solución perfecta.
3. Los sistemas son productos (aunque te duela)
Otra idea incómoda del post: un sistema interno, una librería, una API, también son productos. Tienen usuarios. Esos usuarios tienen necesidades. Y si no entiendes esas necesidades, vas a construir la solución equivocada.
El autor lo plantea así: tal vez lo que tus usuarios necesitan no es una API HTTP, sino una librería que puedan importar. Tal vez no necesitan un servicio separado, sino un módulo bien encapsulado dentro del mismo código base.
La forma de la solución solo se vuelve obvia cuando tratas el sistema como un producto y defines los requisitos con honestidad.
Y aquí viene la prueba de fuego: si empiezas a preguntar "¿por qué está construido así?" y las respuestas no se sostienen, tienes sobreingeniería. No perfección.
El síntoma que delata todo
Según el post, hay una señal inequívoca de que algo está sobreingenierizado:
Preguntas "¿por qué?" y las respuestas no cierran.
— ¿Por qué tenemos cinco microservicios? —Por escalabilidad. — ¿Cuántos usuarios tenemos? —Trescientas peticiones al día. — ...
Esa pausa incómoda es el diagnóstico. Resolviste un problema que no tenías, con la mejor intención, y terminaste con un sistema más complejo, más frágil y más caro de mantener.
La solución no es dejar de hacer las cosas bien. Es definir mejor los requisitos. Poner todas las restricciones sobre la mesa. Entender el problema real antes de escribir una sola línea de código.
¿Qué significa esto para tu día a día?
La próxima vez que alguien te diga "no seas perfeccionista" en un code review, pregúntate: ¿estoy resolviendo el problema equivocado o estoy haciendo mi trabajo con cuidado?
Hay una diferencia enorme entre:
- Pensar la arquitectura antes de codificar → profesionalismo
- Añadir abstracciones para casos de uso que nunca llegarán → sobreingeniería
- Escribir código limpio que tu yo del futuro pueda entender → respeto por tu trabajo
- Optimizar antes de medir → error
No dejes que el miedo a la sobreingeniería te impida escribir buen código. El enemigo no es la perfección. Son los requisitos ambiguos.
Comparte esto con ese compañero que todavía cree que hacer las cosas bien es una pérdida de tiempo. Tal vez el próximo code review sea más productivo.