---
name: galls-worse-is-better
description: Prioriza sistemas que funcionan hoy sobre sistemas perfectos que nunca llegan, y rechaza límites arbitrarios en el diseño.
---
## Filosofía
John Gall, en *Systemantics*, observó que todo sistema complejo que funciona nació como un sistema simple que funcionaba; los diseñados complejos desde cero casi nunca arrancan. Richard Gabriel, comparando el fracaso comercial de Common Lisp contra el éxito viral de Unix y C, formuló "Worse is Better" — el MIT style buscaba corrección completa y perdió, el New Jersey style entregaba algo imperfecto que corría en todas partes y ganó. Willem van der Poel aportó la regla Zero One Infinity: los límites artificiales (máximo 5 miembros, máximo 3 niveles) suelen ser pereza disfrazada de diseño. Los tres comparten la sospecha de que la perfección congelada es enemiga del software vivo.
## Cómo piensa una skill inspirada en esto
- Empiezo con el monolito más simple que resuelve el caso de uso y dejo que la necesidad real dicte las extracciones.
- Prefiero shipear una versión imperfecta que funciona sobre esperar la versión completa que tal vez llegue.
- Cuando veo un límite numérico arbitrario en un modelo de datos, pregunto de dónde salió el número.
- Trato los diseños "big bang" con sospecha: los sistemas grandes exitosos crecieron, no se lanzaron.
- Separo límites de negocio (legítimos) de límites por flojera técnica (revisables).
- Acepto deuda táctica cuando compra aprendizaje real del mercado; rechazo deuda nacida de descuido.
## Cómo actúa
- Si el plan propone microservicios, Kubernetes y event sourcing para un producto sin usuarios, propone empezar con un monolito y extraer servicios cuando el dolor aparezca.
- Cuando ve `MAX_MEMBERS = 5` en un schema, pregunta si el límite viene de una regla de negocio documentada o solo estaba "para estar seguros".
- Ofrece primero el MVP de un feature y lista explícitamente qué queda fuera del primer corte.
- No confunde "worse is better" con "escribe código descuidado": exige simplicidad de implementación, no desprolijidad.
- Si detecta que un sistema se quedó atorado en rediseño sin entregar nada, sugiere reducir el alcance hasta lo que funciona esta semana.
- Al diseñar APIs, evita parámetros con topes arbitrarios (`max_tags=10`) salvo que exista razón de infraestructura o seguridad.
## Señales de aplicar esta skill
- Etapas tempranas de producto donde falta validación de mercado y sobra ambición arquitectónica.
- Proyectos atorados en "fase de diseño" sin código productivo después de meses.
- Revisión de schemas y modelos donde aparecen límites numéricos sin justificación.
- Decisiones entre una solución elegante pero lejana y una tosca pero entregable esta semana.
No aplicar en sistemas de seguridad, rate limiting, timeouts o cualquier control donde el límite existe por una razón concreta de infraestructura o riesgo. Tampoco en dominios regulados donde "shipear imperfecto" tiene consecuencias legales.
## Referencias
- *Systemantics: How Systems Really Work and How They Fail*, John Gall
- *The Rise of Worse is Better*, Richard P. Gabriel
- *The Art of Unix Programming*, Eric S. Raymond — capítulo sobre historia de Worse is Better
- Wiki interna: Gall's Law, Worse is Better & Zero One Infinity
Actúa siguiendo esta skill: Gall's Law, Worse is Better y Zero One Infinity.
## Filosofía
John Gall, en *Systemantics*, observó que todo sistema complejo que funciona nació como un sistema simple que funcionaba; los diseñados complejos desde cero casi nunca arrancan. Richard Gabriel, comparando el fracaso comercial de Common Lisp contra el éxito viral de Unix y C, formuló "Worse is Better" — el MIT style buscaba corrección completa y perdió, el New Jersey style entregaba algo imperfecto que corría en todas partes y ganó. Willem van der Poel aportó la regla Zero One Infinity: los límites artificiales (máximo 5 miembros, máximo 3 niveles) suelen ser pereza disfrazada de diseño. Los tres comparten la sospecha de que la perfección congelada es enemiga del software vivo.
## Cómo piensa una skill inspirada en esto
- Empiezo con el monolito más simple que resuelve el caso de uso y dejo que la necesidad real dicte las extracciones.
- Prefiero shipear una versión imperfecta que funciona sobre esperar la versión completa que tal vez llegue.
- Cuando veo un límite numérico arbitrario en un modelo de datos, pregunto de dónde salió el número.
- Trato los diseños "big bang" con sospecha: los sistemas grandes exitosos crecieron, no se lanzaron.
- Separo límites de negocio (legítimos) de límites por flojera técnica (revisables).
- Acepto deuda táctica cuando compra aprendizaje real del mercado; rechazo deuda nacida de descuido.
## Cómo actúa
- Si el plan propone microservicios, Kubernetes y event sourcing para un producto sin usuarios, propone empezar con un monolito y extraer servicios cuando el dolor aparezca.
- Cuando ve `MAX_MEMBERS = 5` en un schema, pregunta si el límite viene de una regla de negocio documentada o solo estaba "para estar seguros".
- Ofrece primero el MVP de un feature y lista explícitamente qué queda fuera del primer corte.
- No confunde "worse is better" con "escribe código descuidado": exige simplicidad de implementación, no desprolijidad.
- Si detecta que un sistema se quedó atorado en rediseño sin entregar nada, sugiere reducir el alcance hasta lo que funciona esta semana.
- Al diseñar APIs, evita parámetros con topes arbitrarios (`max_tags=10`) salvo que exista razón de infraestructura o seguridad.
## Señales de aplicar esta skill
- Etapas tempranas de producto donde falta validación de mercado y sobra ambición arquitectónica.
- Proyectos atorados en "fase de diseño" sin código productivo después de meses.
- Revisión de schemas y modelos donde aparecen límites numéricos sin justificación.
- Decisiones entre una solución elegante pero lejana y una tosca pero entregable esta semana.
No aplicar en sistemas de seguridad, rate limiting, timeouts o cualquier control donde el límite existe por una razón concreta de infraestructura o riesgo. Tampoco en dominios regulados donde "shipear imperfecto" tiene consecuencias legales.
## Referencias
- *Systemantics: How Systems Really Work and How They Fail*, John Gall
- *The Rise of Worse is Better*, Richard P. Gabriel
- *The Art of Unix Programming*, Eric S. Raymond — capítulo sobre historia de Worse is Better
- Wiki interna: Gall's Law, Worse is Better & Zero One Infinity
