¿Qué significa KISS?

El principio KISS es un acrónimo del inglés Keep It Simple, Stupid (en español: "Mantenlo Simple, Estúpido"). Es un principio de diseño que establece que la mayoría de los sistemas funcionan mejor si se mantienen simples en lugar de complicados. La simplicidad debe ser un objetivo clave del diseño, y la complejidad innecesaria debe evitarse siempre que sea posible.

KISS no se refiere a crear soluciones simplistas o incompletas, sino a buscar la forma más directa, clara y comprensible de resolver un problema. Un sistema simple es más fácil de entender, mantener, depurar y evolucionar que uno complejo.

El principio KISS se atribuye al ingeniero aeronáutico Kelly Johnson, quien lideró los famosos "Skunk Works" de Lockheed Martin (el departamento de proyectos avanzados de la compañía aeroespacial). Johnson utilizaba esta frase como directriz de diseño para los aviones militares que su equipo desarrollaba, aproximadamente en 1960.

La idea detrás del principio era que los aviones debían poder ser reparados por un mecánico promedio en condiciones de combate con herramientas limitadas. Si el diseño era demasiado complejo, los aviones serían imposibles de mantener en el campo de batalla. Esta restricción obligaba a los ingenieros a buscar soluciones elegantemente simples.

Existen variaciones del acrónimo que evitan la palabra "stupid" para hacerlo más apropiado en entornos profesionales:

• Keep It Short and Simple
• Keep It Simple and Straightforward
• Keep It Super Simple

En el desarrollo de software, el principio KISS se aplica en múltiples niveles y es uno de los fundamentos de la buena ingeniería de software.

Código simple y legible

El código se lee muchas más veces de las que se escribe. Un código simple y legible reduce el tiempo de comprensión, facilita las revisiones de código y disminuye la probabilidad de introducir bugs al hacer modificaciones.

Ejemplo de violación del principio KISS:

// Complejo e innecesario const isEven = (n) => !(n & 1) ? true : false; const result = arr.reduce((a, c) => isEven(c) ? [...a, c * 2] : a, []);

Ejemplo aplicando KISS:

// Simple y claro const evenNumbers = arr.filter(n => n % 2 === 0); const result = evenNumbers.map(n => n * 2);

Ambos fragmentos producen el mismo resultado, pero la segunda versión es inmediatamente comprensible para cualquier desarrollador, mientras que la primera requiere un análisis más detallado.

Arquitectura de software

En la arquitectura de software, KISS se traduce en:

• Evitar la sobreingeniería: no diseñar para requisitos que no existen. Construir la solución más simple que satisfaga los requisitos actuales y conocidos.
• Preferir soluciones probadas: utilizar patrones de diseño y tecnologías conocidas en lugar de inventar soluciones propias cuando ya existen alternativas establecidas.
• Minimizar las dependencias: cada dependencia añade complejidad. Evaluar si una librería o servicio externo realmente aporta valor suficiente para justificar su coste en complejidad.
• Monolito antes que microservicios: para muchos proyectos, un monolito bien estructurado es más simple y apropiado que una arquitectura de microservicios, especialmente en las etapas iniciales.

Diseño de APIs

Una API que sigue el principio KISS es intuitiva, consistente y predecible:

• Nombres de endpoints claros y descriptivos.
• Convenciones consistentes en toda la API.
• Respuestas predecibles y bien documentadas.
• Mínimo número de parámetros necesarios para cada operación.

Diseño de interfaces de usuario

En el diseño de interfaces de usuario (UI), KISS se manifiesta en:

• Interfaces limpias y libres de elementos innecesarios.
• Flujos de navegación intuitivos y directos.
• Reducción de opciones para evitar la parálisis de decisión.
• Priorización de la claridad sobre la decoración.

KISS no existe de forma aislada, sino que se complementa con otros principios de diseño de software:

YAGNI (You Aren't Gonna Need It)

YAGNI establece que no se debe implementar funcionalidad que no se necesita actualmente. Complementa a KISS al prevenir la sobreingeniería: si no lo necesitas ahora, no lo construyas.

DRY (Don't Repeat Yourself)

DRY aboga por evitar la duplicación de código y conocimiento. Aunque DRY y KISS suelen ser complementarios, en ocasiones pueden entrar en conflicto: la abstracción necesaria para eliminar duplicación puede añadir complejidad. En esos casos, a veces es preferible una duplicación simple a una abstracción compleja.

SOLID

Los principios SOLID promueven un diseño orientado a objetos limpio y mantenible. El Principio de Responsabilidad Única (Single Responsibility Principle) es particularmente afín a KISS: cada clase o módulo debe tener una única responsabilidad, lo que lo mantiene simple y enfocado.

Principio de menor sorpresa (Principle of Least Astonishment)

Este principio establece que un componente de software debe comportarse de la manera que los usuarios esperan. Se alinea con KISS al promover soluciones predecibles y comprensibles.

Ley de Gall

La Ley de Gall afirma que "un sistema complejo que funciona invariablemente ha evolucionado a partir de un sistema simple que funcionaba". Esto refuerza KISS: empieza simple y permite que la complejidad crezca orgánicamente según sea necesario.

El principio KISS está profundamente alineado con los valores y principios ágiles:

• El Manifiesto Ágil valora "la simplicidad: el arte de maximizar la cantidad de trabajo no realizado".
• Scrum promueve la entrega de incrementos mínimos viables en cada sprint.
• Kanban busca simplificar el flujo de trabajo y eliminar el desperdicio.
• Extreme Programming incluye la simplicidad como uno de sus valores fundamentales, promoviendo el concepto de "Do The Simplest Thing That Could Possibly Work".

Antes de diseñar

1. Entender claramente el problema antes de pensar en la solución.
2. Identificar los requisitos reales, no los hipotéticos.
3. Buscar soluciones existentes antes de construir algo nuevo.

Durante el desarrollo

1. Escribir código claro y autoexplicativo.
2. Preferir nombres descriptivos a comentarios explicativos.
3. Mantener las funciones cortas y con un propósito único.
4. Evitar optimizaciones prematuras.
5. Refactorizar constantemente para mantener la simplicidad.

En la revisión

1. Preguntar "¿existe una forma más simple de hacer esto?" en cada code review.
2. Cuestionar la necesidad de cada capa de abstracción.
3. Evaluar si la complejidad añadida está justificada por un requisito real.

• Confundir simple con simplista: KISS no significa tomar atajos ni ignorar la complejidad inherente del problema. Significa gestionar esa complejidad de la forma más elegante posible.
• Usarlo como excusa para no aprender: "mantenerlo simple" no debe ser una excusa para no aprender mejores patrones o técnicas cuando son apropiados.
• Aplicarlo de forma dogmática: en algunos casos, una solución más compleja puede ser la correcta si ofrece beneficios claros en rendimiento, seguridad o mantenibilidad a largo plazo.
• Ignorar el contexto del equipo: lo que es "simple" depende del nivel de experiencia del equipo. Una solución que utiliza patrones avanzados puede ser simple para un equipo experto pero compleja para uno junior.

Diversos pensadores y profesionales han expresado ideas alineadas con el principio KISS:

• Leonardo da Vinci: "La simplicidad es la máxima sofisticación."
• Albert Einstein: "Todo debería hacerse tan simple como sea posible, pero no más simple."
• Antoine de Saint-Exupéry: "La perfección se alcanza, no cuando no hay nada más que añadir, sino cuando no hay nada más que quitar."
• Martin Fowler: "Cualquier tonto puede escribir código que una computadora entienda. Los buenos programadores escriben código que los humanos entienden."

¿KISS significa que no debo usar patrones de diseño?

No. Los patrones de diseño existen para resolver problemas recurrentes de forma probada. KISS significa que no debes aplicar patrones de diseño innecesariamente. Usa un patrón cuando resuelva un problema real, no porque quieras demostrar que lo conoces.

¿Cómo equilibrar KISS con la necesidad de código escalable?

La clave está en diseñar para los requisitos conocidos actuales con una arquitectura que permita evolucionar. Empieza simple y refactoriza cuando la complejidad adicional esté justificada por requisitos reales. Evita construir abstracciones "por si acaso" antes de que sean necesarias.

¿KISS se aplica solo al código?

No. KISS se aplica a todos los aspectos del trabajo: procesos, documentación, comunicación, arquitectura, diseño de interfaces, configuración de herramientas y cualquier sistema que pueda simplificarse sin perder funcionalidad.

¿Cuál es la diferencia entre KISS y YAGNI?

KISS se centra en mantener las soluciones simples y comprensibles. YAGNI se centra en no implementar funcionalidad que no se necesita actualmente. Son complementarios: YAGNI previene la adición de funcionalidad innecesaria y KISS asegura que lo que sí se construye se haga de la forma más simple posible.

¿Cómo convencer a mi equipo de que la solución simple es mejor?

Presentar argumentos concretos: el código simple tiene menos bugs, es más fácil de mantener, se entiende más rápido y permite incorporar nuevos miembros del equipo con menos fricción. Cuando sea posible, mostrar datos comparativos de mantenimiento entre componentes simples y complejos del mismo proyecto.