Saltar al contenido

Principio KISS – Keep It Simple, Stupid

keep it simple stupid

El principio KISS (Keep It Simple, Stupid) es un principio del diseño que establece que todo sistema funciona mejor cuanto más sencillo es. Es un principio aplicable a casi cualquier disciplina aunque aquí hablaremos de su uso en sistemas software.

Orígenes y variantes

Se atribuye a Kelly Johnson cuando intentaba con su equipo crear un avión a reacción que fuese capaz de ser reparado con un conjunto de herramientas limitado y por un mecánico medio bajo condiciones de combate. Otros sitúan su origen en herramientas y presentaciones de marketing y ventas que pretendían evitar que los sucesivos diseños se complicaran en exceso.

Existen numerosas variantes de sus siglas pero todas con la misma idea de trasfondo:

  • keep it short and simple: «Mantenlo corto y simple»
  • keep it simple and straightforward: «Mantenlo simple y directo»
  • keep it small and simple: «Mantenlo pequeño y simple»

Incluso sin usar este acrónimo podemos rastrear este principio al mismo Leonardo Da Vinci que dijo «La sencillez es la sofisticación definitiva» o a William de Ockham que postulo que la solución más sencilla es a menudo la correcta (la navaja de Occam).

Desarrollo Software

En cuanto al desarrollo software, el principio KISS pretende mantener la simplicidad como un requisito u objetivo del diseño. Esto por si mismo ya es una ventaja. Manteniendo sencillo el sistema acortamos el tiempo de desarrollo y facilitamos el mantenimiento del mismo. Para conseguir esto es fundamental subdividir los problemas complejos en subelementos más sencillos.

Otra de las implicaciones de este principio es que no debemos complicar el sistema de forma innecesaria. Por tanto, si en este momento una característica no es necesaria es mejor no añadirla. Siempre habrá tiempo para refactorizar el código y agregar funcionalidades. Muchos desarrolladores piensan que añadiéndolo todo desde el principio el sistema es mucho más flexible y ahorran tiempo al tener el sistema preparado para todo lo que pueda venir. En realidad consiguen el efecto contrario:

  • Por un lado aumentamos el tiempo de desarrollo con funcionalidades que puede que nunca sean necesarias. De hecho se estima que dos tercios de todo el software que se desarrolla nunca llega a usarse.
  • El sistema se vuelve más complejo por lo que el mantenimiento es más lento y problemático. Cada funcionalidad que se desarrolle será más compleja de añadir por lo que generará más errores y costará más tiempo.
  • Finalmente, no importa lo mucho que podamos conocer sobre los clientes, nunca podremos desarrollar todas las posibles funcionalidades.

Ante todo esto, lo mejor es desarrollar el sistema más sencillo posible, y mediante iteraciones y refactorizaciones añadir todas las funcionalidades que se nos requieran una a una. Es en lo que se basan todas las técnicas de desarrollo ágil que están tan de moda hoy en día.

Conclusión

Aunque puede parecer algo sencillo, mantener la sencillez del sistema con forme este crece es sumamente complicado. Mi recomendación es que estudiéis muy detenidamente los requisitos que os piden, y a ser posible, que habléis directamente con el cliente o con el dueño del producto (Product Owner) para tener muy claros los objetivos y problemas a solucionar. Una vez claros estos objetivos hay que mantenerse en dicha linea y no especular o realizar hipótesis sobre lo que pueda o no necesitar el cliente el día de mañana.

Espero que os haya resultado útil.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.