¿Qué es "worse is better"?
Cultura de ingeniería y práctica de software
Worse is better es una idea de diseño de software asociada a Richard Gabriel. Sostiene, de forma provocadora, que un sistema más sencillo de construir, más fácil de portar y suficientemente bueno en los casos importantes puede extenderse más rápido que un rival más completo o elegante. Los ingenieros usan la expresión para hablar de adopción, compromisos y el incómodo hecho de que el sistema que triunfa en el mundo no siempre es el que parece más refinado sobre el papel.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
El nombre parece un elogio de la mediocridad. No es tan sencillo. La expresión surgió del contraste entre dos estilos de diseño. Uno intenta que todo sea conceptualmente correcto desde el principio. El otro está dispuesto a lanzar algo más limitado y menos pulido si es lo bastante simple para implementarse y difundirse.
Esa tensión sigue siendo familiar. Los equipos eligen con frecuencia entre una plataforma amplia, ordenada y ambiciosa, y una herramienta más pequeña y menos completa que es más fácil de construir, de entender y de adoptar por otras personas.
Por qué importa
Esta idea importa porque el éxito del software no se decide únicamente por la elegancia. También lo determinan la portabilidad, el momento oportuno, la comprensión, los límites de recursos y la disposición de las personas corrientes a adoptar algo y usarlo. Worse is better da nombre a esa verdad incómoda.
También importa porque la expresión se abusa con frecuencia. En buenas manos, describe un compromiso disciplinado. En malas manos, se convierte en un eslogan para recortar atajos y dejar un desastre atrás. Entender la idea original ayuda a distinguir un diseño mínimo viable de uno simplemente descuidado.
Cómo funciona
El origen del término
Richard Gabriel introdujo la expresión en el contexto de Lisp, Unix y las ideas en competencia sobre el buen diseño. Según su propio relato, comenzó como una broma interna en Lucid en 1989, se convirtió en una conferencia magistral y luego pasó a ser la parte más conocida de su artículo "Lisp: Good News, Bad News, How to Win Big". El famoso fragmento contrastaba lo que él llamó el enfoque MIT, apodado a menudo "the right thing", con un enfoque "New Jersey" basado en la simplicidad de implementación.
Ese contexto histórico importa porque impide que la expresión se reduzca a una pegatina de parachoques para el trabajo descuidado. Gabriel sabía que estaba caricaturizando los dos bandos para hacer el compromiso más vívido. Más adelante escribió tanto en contra como a favor de la idea, y nunca adoptó una postura de defensor simple y triunfante.
Qué significan "worse" y "better"
En el planteamiento de Gabriel, "the right thing" también valora la simplicidad, pero se preocupa especialmente por tener una interfaz simple, coherencia conceptual, corrección y completitud amplia. Worse is better reordena esas prioridades. Trata la simplicidad de implementación como la primera preocupación y está más dispuesto a sacrificar la completitud, y a veces una interfaz más fluida, para lograrla.
Eso parece absurdo hasta que se visualizan los efectos prácticos. Un núcleo más simple suele ser más fácil de portar, de explicar, de reimplementar y de mejorar de forma incremental. Si llega a suficientes personas con rapidez, gana distribución, presencia mental y un ecosistema en crecimiento. En ese punto, el diseño imperfecto puede mejorarse desde una posición de fortaleza.
Así que la expresión trata realmente de características de supervivencia. El "better" del nombre significa mejor para abrirse camino en el mundo y mantenerse en él. No significa automáticamente más bello, más humano ni más correcto en todos los aspectos.
Por qué la idea sigue reapareciendo
El software recompensa repetidamente lo que es suficientemente pequeño, suficientemente simple y disponible con suficiente rapidez. Los equipos lo comprueban cuando una utilidad de línea de comandos estrecha supera a una plataforma gigante, o cuando un formato de archivo sencillo se extiende más que uno teóricamente más limpio. Un sistema que exige menos a quienes lo implementan y adoptan puede llegar más lejos.
Por eso la idea también genera debates. Los ingenieros tienen razón al preocuparse de que una victoria a corto plazo pueda convertirse en una carga a largo plazo. Si lo que se extiende es demasiado tosco, todos pueden acabar asumiendo el coste. El propio Gabriel reconoció esa tensión. Sus escritos posteriores muestran fascinación por el poder explicativo de la idea e incomodidad con sus efectos culturales.
Cómo se manifiesta en el trabajo real
En los equipos modernos, worse is better suele aparecer de forma más discreta y menos ideológica. Un equipo puede elegir una interfaz estrecha que cubre la mayoría de los casos con claridad en lugar de una gran abstracción que intenta manejar todas las posibilidades futuras. Un equipo de producto puede lanzar un único flujo de trabajo que funcione bien para el camino habitual en lugar de un panel de configuración extenso para cada caso concebible. Un equipo de plataforma puede preferir una herramienta fácil de ejecutar y ampliar por otros, aunque carezca de cierta elegancia.
La pregunta clave es si el diseño reducido sigue siendo básicamente sólido. Los propios escritos de Gabriel sugieren repetidamente que la cosa pequeña debe seguir siendo suficientemente buena en el núcleo. Si el núcleo está podrido, la expresión se convierte en una hoja de parra para el mal juicio.
Por qué la expresión sigue mereciendo la pena
La expresión sobrevive porque ayuda a los equipos a plantearse una pregunta difícil. ¿Estamos apuntando a la perfección conceptual cuando el problema real es la adopción, la portabilidad y el momento oportuno? ¿O nos escudamos en la simplicidad cuando en realidad estamos evitando el trabajo de diseño necesario? Bien utilizada, la expresión no zanja el debate. Lo afila.
Ejemplos
Un equipo está diseñando un sistema de flujo de trabajo interno. Una propuesta es un motor amplio y altamente configurable con un modelo denso y decenas de puntos de extensión. Otra es un servicio más pequeño que gestiona el ochenta por ciento de los casos con convenciones claras y solo unos pocos puntos de enganche. Si el servicio más pequeño es sólido, los equipos pueden llegar a usarlo de verdad, y el uso puede enseñar a los creadores qué merece venir después.
Una startup tiene que elegir entre un cliente de escritorio refinado con muchas funciones integradas y una versión web más tosca que es más fácil de distribuir y actualizar. La versión web puede ganar porque la propiedad importante es el alcance, no la pulcritud conceptual.
Un equipo de plataforma puede empaquetar una herramienta con dependencias pesadas y una superficie de control pulida, o crear una versión más simple que funcione en infraestructura ordinaria y pueda ser comprendida por más ingenieros. La opción menos vistosa puede generar una curva de adopción más saludable.
Malentendidos frecuentes
Un malentendido habitual es pensar que worse is better significa "lo malo es bueno". No es así. La idea depende de que la cosa más pequeña sea básicamente buena donde más importa.
Otro error es leerlo como una ley universal. Algunos ámbitos penalizan severamente la incompletitud. En trabajos de seguridad crítica, controles financieros o sistemas de seguridad fundamentales, la simplificación agresiva puede ser imprudente.
También hay quienes lo convierten en un eslogan contra el diseño. El concepto original está lleno de juicio de diseño. Trata de elegir qué tipo de simplicidad se gana el derecho a crecer.
Por último, muchas versiones del relato olvidan la ambivalencia de Gabriel. Estaba explicando un patrón en el mundo, no entregando a todo el mundo un permiso moral.
Riesgos y límites
La versión mala de worse is better genera hostilidad en los usuarios, fragilidad operativa y deuda permanente. Los equipos anuncian que un primer corte delgado y torpe es estratégico, y luego nunca regresan a las partes que aplazaron conscientemente. En ese punto, el "better" ha desaparecido en silencio.
La versión buena tiene límites. Se mantiene el núcleo sólido. Se sabe qué aristas toscas son temporales y cuáles son aceptables. Se usa la simplicidad para acelerar el aprendizaje y la difusión, no para eludir la corrección indefinidamente.
Una prueba útil es esta: si el diseño tiene más éxito del esperado, ¿seguirá siendo comprensible y manejable el compromiso adoptado? Si la respuesta es no, puede que se esté construyendo algo simplemente peor.
Qué hacer a continuación
Si esta tensión está viva en el equipo, conviene sacar el compromiso a la luz. Hay que preguntarse para qué se está optimizando en este momento: pureza conceptual, simplicidad de implementación, tiempo hasta la adopción, portabilidad o facilidad de operación. No se debe permitir que nadie pretenda maximizar todo a la vez.
Si se elige el camino más ligero, conviene definir el suelo con claridad. ¿Qué debe ser correcto desde el primer día? ¿Qué puede aplazarse? ¿Qué evidencia indicará si el diseño simplificado se está extendiendo de verdad y ganando el derecho a crecer? Luego hay que programar el segundo movimiento. La simplicidad es poderosa, pero solo si conduce al aprendizaje en lugar de al abandono cómodo.
Bien utilizada, la expresión debería hacer a los equipos más reflexivos, no más descuidados.
¿Tiene alguna pregunta o sugerencia, o quiere saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Significa worse is better que debemos lanzar productos malos?
No. Significa que un diseño más pequeño y simple puede extenderse con más eficacia que un rival más completo si el núcleo es sólido.
¿Por qué la expresión es tan provocadora?
Porque ofende deliberadamente el instinto de que el diseño más elegante siempre debería ganar. En la práctica, la adopción suele recompensar también otras cualidades.
¿Qué son los estilos MIT y New Jersey?
Son las etiquetas de Gabriel para dos órdenes de prioridad de diseño distintos: uno centrado en lograr que el concepto sea ampliamente correcto, y el otro en mantener la implementación más simple y portable.
¿Respaldó realmente Richard Gabriel la idea?
La originó y defendió su poder explicativo, pero también la criticó más adelante y mantuvo una postura notablemente ambivalente.
¿Es esto solo otro nombre para "producto mínimo viable"?
No exactamente. Hay cierta superposición, pero worse is better trata más específicamente de las prioridades de diseño y de por qué las implementaciones más simples pueden extenderse con más éxito.
¿Cuándo es peligrosa la idea?
Es peligrosa cuando los equipos la usan para justificar una corrección deficiente, una usabilidad pobre o la negativa a mejorar el primer corte tosco.