Sobreingeniería: el arte de resolver problemas que aún no existen [Actualización 2025]
Descubre por qué la sobreingeniería es uno de los mayores peligros para tu startup o producto digital. Analizamos qué es y cómo prevenirla.
Cuando leáis estas líneas, estaré volando de vuelta a casa tras pasar unos días de vacaciones con la familia. Sin tiempo para escribir, he aprovechado para revisar otro artículo clásico de la lista de correo, uno que en su edición en inglés llegó a ser top 1 en Hacker News. ¡Espero que lo disfrutéis!
Si nos vamos a la definición estricta de la Wikipedia, el término sobreingenería se refiere al hecho de diseñar un producto de forma más compleja de lo necesario:
Overengineering (or over-engineering,[1] or over-kill) is the act of designing a product or providing a solution to a problem in an overly complicated manner, where a simpler solution can be demonstrated to exist with the same efficiency and effectiveness as that of the original design.[2] — Wikipedia
En el contexto del software, me gusta esta definición de Paweł Głogowski:
Code or design that solves problems you don’t have.
Ahora pensaréis, ¿quién diseña o programa para resolver un problema que no tiene? Parece ridículo, ¿verdad? Después de más de dos décadas de carrera, os puedo asegurar que la sobreingeniería no es la excepción, suele ser la norma.
Causas de la sobreingenería
Obviamente, nadie lo hace con mala intención. De hecho en muchas ocasiones la sobreingeniería se produce por querer anticipar el futuro y cubrirse ante lo desconocido.
Cuando programamos una funcionalidad es fácil pensar que invirtiendo un poquito de tiempo podemos dejar lista, para, “por si acaso”, en el futuro nos pidieran esto otro.
La realidad es que nueve de cada diez veces ese “por si acaso” nunca llega. Sólo perdemos un valioso tiempo y, lo que es peor, incrementamos la complejidad del producto, algo que arrastraremos a lo largo de toda la vida del mismo.
Otra causa de la sobreingeniería suele ser la falta de experiencia. En general, cuánto más sénior eres, menos ganas de fliparte tienes porque ya has vivido bastantes situaciones donde la complejidad artificial te ha explotado en la cara.
La curva de aprendizaje respecto a la experiencia de un ingeniero suele seguir un patrón bastante parecido a este:
Empiezas programando código sencillo.
Descubres un paradigma, como podría ser la programación orientada a objetos, y te subes al carro.
Lees sobre patrones de diseño y empiezas a buscar la oportunidad para implementarlos en cada proyecto.
Tras unos años de haber sufrido la complejidad innecesaria en tus carnes, vuelves a escribir código sencillo.
Los requisitos poco definidos obviamente también incrementan este problema. Si un ingeniero no tiene bien acotado un problema, tenderá a la sobreingeniería para protegerse de la incertidumbre.
El aburrimiento también puede generar sobreingeniería. Si un ingenierio no tiene retos interesantes a los que enfrentarse es posible que termine complicando cualquier problema por el simple hecho de probar algo nuevo.
Consecuencias de la sobreingeniería
Cuando decía al principio del artículo que la sobreingeniería mata startups, no lo decía irónicamente. Esta tiene dos efectos particularmente perversos en cualquier sistema.
Por una parte, aumenta el coste de desarrollo. Si nuestros ingenieros no eligen la solución más sencilla para abordar un problema, nuestro coste de desarrollo en tiempo y dinero aumenta, lo que evitará que iteremos más rápido.
Por otra parte, también aumenta el coste de mantenimiento. El código sencillo es mucho más fácil de programar, probar y modificar. Cuando lo complicamos, la complejidad puede aumentar de forma exponencial, de nuevo impactando en nuestra velocidad de iteración.
Así pues, me reafirmo. La sobreingeniería mata startups. Mucho más que la ausencia de buenas prácticas. Y es que para cobrar el beneficio de las buenas prácticas hay que llegar a tener encaje en el mercado, pero la sobreingeniería puede evitar que llegues a tenerlo.
Ejemplos de sobreingenería
El primero que me viene a la mente son las arquitecturas basadas en microservicios. Llegaron como una ola hace unos años y se deben haber llevado más proyectos por delante de los que han consolidado.
Las pongo como ejemplo de sobreingeniería porque en el 99% de los casos no son necesarias, especialmente para una startup que tenga que encontrar market-fit. Dedícate a encontrarlo a lomos de un majestuoso monolito que te permita iterar a toda velocidad. Si lo encuentras y resulta que terminas necesitando pasarte a microservicios, significará que has alcanzado una escala considerable y oye, ese es un bendito problema a tener.
La optimización prematura suele ser otro ejemplo típico de sobreingeniería. Preparar un sistema para operar con latencias muy bajas o absorber gran cantidad de tráfico cuando, ni tienes usuarios, ni probablemente sepas cómo serán y qué nivel de servicio necesitarán. Vuelvo arriba. En la mayoría de los casos, con un monolito corriendo en un único servidor te servirá para validar tu modelo de negocio.
Uno de los peores ejemplos de optimización prematura se da cuando nos pasamos mucho tiempo diseñando un sistema con la excusa de evitar tener que rehacer trabajo en el futuro. Créeme, de nada sirve diseñar un sistema si no llegas a verlo en funcionamiento porque has quebrado antes. El peor código del planeta que te ayude a validar una hipótesis es mejor que quedarte paralizado tratando de cubrir todos los casos de uso futuros con un diseño impecable.
Relacionado con lo anterior, los proyectos de reescritura son un ejemplo clarísimo de sobreingeniería. A ningún ingeniero le gusta mantener código que ha hecho otro. La tendencia natural es a querer hacerlo todo siempre de cero. Pero como Joel escribió hace más de 20 años en Things you should never do, las reescrituras raramente cumplen su propósito y pueden llevarse a tu empresa por delante.
Suena hasta raro decirlo por lo evidente, pero a tu cliente no le importa lo más mínimo lo elegante que sea tu sistema por dentro. A tu cliente le importa que le ayudes a resolver su problema. Todo minuto invertido en no darle valor es un minuto perdido.
¿Cómo prevenir la sobreingeniería?
La mejor forma de prevenir la sobreingeniería desde mi punto de vista es convertir a tus ingenieros en verdaderos ingenieros de producto.
Eso se consigue involucrándolos en el día a día del negocio, explicándoles el por qué de cada iniciativa que se plantea, enlanzándola con las métricas que importan para la organización y con la visión de la misma.
También acercándoles a los usuarios, invitándolos a entrevistas y sesiones de discovery con ellos. Quieres que tu equipo empatice con tu cliente o usuario, de forma que consideren un desperdicio todo lo que no sea resolver sus problemas de la forma más eficiente posible.
Si tratas a tus ingenieros como meras piezas de un engranaje cuya única tarea es implementar historias de usuario que aparecen por arte de magia en un backlog, no esperes que estén motivados por evitar complejidad.
Relacionado con lo anterior, define bien el problema para reducir la ambigüedad. Tus ingenieros necesitan saber el por qué, pero también necesitan saber qué se espera de ellos. Cuánto más puedas acotar el problema, menos razones tendrán para protegerse. Una buena forma de definir las expectativas de un sistema es utilizando objetivos de servicio utilizando SLIs y SLOs.
Los ingenieros son de los perfiles más creativos en cualquier empresa. Si tu equipo confía en tu criterio, es probable que en el día a día surjan ideas o iniciativas de su parte que puedan evidenciar que están pensando en un caso de uso futuro. Cuando tengas la intuición de que esto pueda ser así, pregunta: ¿Cómo ayuda esto a resolver el problema actual de nuestros usuarios? ¿Qué sucede si no lo hacemos ahora? La respuesta te ayudará a discriminar si realmente se trata de un posible caso de sobreingeniería o no. Recuerda la importancia de mantener el foco.
Por último, más orientado a fundadores, contrata en lo posible a ingenieros sénior que ya hayan tenido unas cuántas experiencias en empresas de producto. Busca cicatrices de guerra durante las entrevistas. Pregunta por sus experiencias más dolorosas y cómo hicieron para solventarlas. Quédate con aquellos que ponen por delante al usuario y la simplicidad antes que la tecnología.
Un error común suele ser considerar la tecnología como cuello de botella. En muy pocas ocasiones realmente lo es. Cualquier ingeniero sénior puede programar en cualquier otro lenguaje con un periodo mínimo de adaptación.
Modelos mentales para prevenir la sobreingeniería
YAGNI
El problema de la sobreingeniería es tan evidente en la industria que los propios ingenieros tienen un término para referirse al hecho de añadir una funcionalidad “por si acaso”: YAGNI, acrónimo de “You are not going to need it”.
Básicamente YAGNI trata de evitar que añadas nada que no sea estrictamente necesario para resolver el problema que tienes delante de ti porque la realidad es que muy probablemente “no lo vas a necesitar”.
KISS
El término KISS, Keep it simply stupid (“mantenlo estúpidamente simple”) hace referencia al hecho de que los sistemas sencillos son más fáciles de reparar, evolucionar y mantener. Por lo tanto, la simplicidad debe ser uno de los objetivos de cualquier diseño, evitando cualquier complejidad innecesaria.
Worse is better
Con Worse is better, o “cuánto peor mejor”, resaltamos que, llega un punto en el que tener menos opciones es preferible a tener más, porque puede simplificar el uso de nuestro producto y hacerlo atractivo a un segmento más amplio del mercado.
En otras palabras, nos incita a mantener las funcionalidades mínimamente imprescindibles de un producto, evitando añadir grasa pueda añadir complejidad al mismo.
Addition by Subtraction
Relacionado con lo anterior, otro modelo mental que nos puede ayudar a prevenir la sobreingeniería consiste en mejorar un sistema eliminando partes completas del mismo que ya no son necesarias. Escribí sobre ello en este post.
Conclusión
La sobreingeniería tiene el potencial de destruir tu startup:
Añadiendo complejidad innecesaria.
Incrementando los costes de desarrollo y mantenimiento.
Reduciendo tu velocidad de iteración.
Evitando así que llegues a obtener encaje en el mercado.
Lamentablemente, la sobreingeniería no es una excepción, es la norma. Por ello es vital saber en qué consiste y tratar de prevenirla principalmente involucrando y acercando a tus ingenieros a los problemas reales de tus clientes.
Todo minuto que invirtamos en el desarrollo que no vaya orientado a resolver un problema de nuestros usuarios es un minuto perdido. Evita caer en la trampa de los “por si acaso”.
El cementerio está lleno de startups y productos exquisitamente diseñados para escalar a millones de usuarios que nunca llegaron a tener la más mínima tracción. No te conviertas en uno de ellos.
📝 Referencias
The complexity unlearning curve — Rob Kerr
The Over-Engineering Problem (And How to Avoid It) — ProFocus Technology
Overengineering: Why We Do It and 10 Ways to Tackle It — Amanda Woo
Seven Questions You Can Ask to Prevent Overengineering — Mark Snyder
La sobre ingeniería es algo que (casi) todos y todas tenemos que pasar como desarrolladores.
Cómo líder técnico, que veo que una persona mid está pasando por esta etapa, me ha funcionado mejor que se (nos) metemos la ostia, a intentar explicar el porqué.
Lo importante es:
1. Que la ostia sea reducida, no vamos meter microservicios sino hace falta.
2. Qué aprenda de sus decisiones.
Conseguir pasar de developer a product developer es a través de la experiencia, lo que considero que hace senior a una persona vaya.
En mi caso, tuve la suerte de tener espacio para tomar decisiones, y las que tomé fueron muchas sobre ingeniería, otras fueron mejor, y de esas aprendí. Aprendí porque no funcionaban, y tocó asumir las consecuencias y mejorar todo, a base de mucho dolor.