Principio de lo suficientemente bueno

Aunque se denominó explícitamente en el contexto de la ingeniería de software en la década de 1990, las raíces intelectuales del principio se encuentran en la teoría económica de la racionalidad limitada . En 1956, el premio Nobel Herbert A. Simon introdujo el concepto de Satisficing , una combinación de "satisfy" (satisfacer) y "suffice" (suficiente). Simon argumentó que quienes toman decisiones no poseen la capacidad cognitiva para optimizar cada decisión. En cambio, buscan alternativas solo hasta encontrar una que cumpla con un cierto umbral de aceptabilidad. ^{[ 3 ]}

Con el auge de las metodologías de desarrollo iterativas y ligeras a finales de la década de 1990 y principios de la de 2000, muchos equipos de software dejaron de lado las especificaciones iniciales exhaustivas para adoptar la entrega incremental, la documentación mínima y el diseño adaptativo. La investigación sobre los supuestos subyacentes a las metodologías ágiles identifica un cambio de enfoque hacia el "software funcional" y el refinamiento iterativo en lugar de la ingeniería inicial exhaustiva. ^{[ 4 ]}

Empirical data confirms that within agile teams, documentation often follows a "just enough" pattern. Rather than creating exhaustive artefacts, teams rely on minimal, sufficient documentation to support activity planning and effort estimation.^[5]

Outside of traditional software engineering, the ethos of minimal sufficient design has parallels in other disciplines. In knowledge representation and ontology engineering, for example, proponents have argued for lean, stakeholder-aware approaches rather than heavily formal, resource-intensive ones. The "Just Enough Ontology Engineering" methodology advocates for lightweight conceptual models that are easier to adopt and maintain.^[6]

The shift toward "good enough" software was not universally accepted. In his 2002 book Software Craftsmanship: The New Imperative, Pete McBreen explicitly critiqued the methodology in a chapter titled "The Hazards of the Good Enough Software Approach". McBreen noted that while the principle was originally intended to manage scope, in practice it often reduced the professional standard of software delivery. He argued that it created a harmful distinction between "engineering" a robust solution and merely patching together something that works.^[2]

Este principio se confunde frecuentemente con la filosofía de "lo peor es mejor", popularizada por Richard P. Gabriel . Si bien ambas priorizan la simplicidad, difieren en su enfoque.

• Principio de suficiencia: Se centra en la funcionalidad. Se pregunta: "¿Este producto tiene las características suficientes para resolver el problema del usuario ahora mismo?". Prioriza la utilidad para el usuario sobre la exhaustividad de las funciones.
• Peor es mejor: Se centra en la simplicidad de la implementación. Argumenta que es mejor para la arquitectura del software que sea simple de implementar, incluso si la interfaz es ligeramente menos consistente o correcta. En "Peor es mejor", la simplicidad del código tiene prioridad sobre la perfección funcional. ^{[ 9 ]}

• Regla 80:20
• Desarrollo ágil de software
• Principio KISS
• Minimalismo (informática)
• Producto Mínimo Viable
• Lo perfecto es enemigo de lo bueno.
• Satisfactorio
• No lo vas a necesitar