KISS = Keep It Simple Stupid!

Este principio (KISS) nos dice que en el desarrollo de software, siempre debemos optar por la solución más sencilla (que no por ello es la más fácil de implementar), evitando cualquier indicio de complejidad innecesaria.

El ejemplo máximo de sencillez es la interfaz de usuario de la aplicación con más éxito de la historia, Google: ¿que puede ser mas sencillo que un cuadro de texto y un botón para ejecutar la búsqueda? Otra cosa es la algoritmia y tecnología que hay detrás de estos botones para que todo funcione como se espera, pero el diseño de la aplicación es indiscutiblemente el más sencillo posible.

El principio KISS es fundamental para el diseño de interfaces de usuario, sin olvidarnos del modelo lógico que subyace debajo de los controles y ventanas.

También se aplica al diseño arquitectónico de la aplicación. El diseño tiene que tener tantas capas y componentes como sea necesario para cumplir los requisitos pero nada más. Esto es tan evidente cuando se escribe, como difícil de conseguir. A la hora de diseñar tenemos la tentación de añadir capas y componentes "por si acaso", para hacer el sistema "flexible" y "adaptable" y terminamos por tener una aplicación llena de modulos, componentes y clases que no tienen una función muy clara, y que en lugar de proporcionar la flexibilidad prometida, son un obstáculo a la hora de encontrar errores, optimizar el rendimiento o simplemente evolucionar el sistema. (está relacionado con el principio YAGNI, del que hablaré otro dia)

En un nivel más bajo, en el código, también es importante mantener las ideas claras y el código sencillo. Un código complejo, abigarrado, con métodos de cientos de líneas, condiciones crípticas dentro de los if() o while(), bucles anidados con varios niveles... son un indicador de código de mala calidad, resultado del trabajo descoordinado de varios desarrolladores en diferentes momentos de tiempo, sin una comprensión completa del propósito de dicho código. Por eso es tan importante dedicar tiempo suficiente a la refactorización periódica del código, para mantenerlo limpio, estilizado, coherente, ligero y eficiente.

Normalmente la sencillez es síntoma de que se están haciendo bien las cosas: cuando vemos una competición de esquí, muchas veces podemos distinguir al esquiador bueno por sus movimientos sencillos y sin brusquedades, lo hace "fácil" (aunque esa facilidad aparente sea fruto de miles de horas de entrenamiento). Igual pasa en otros deportes de técnica compleja como el golf, la gimnasia rítmica o incluso el fútbol.

Volviendo al software, un diseño tiene que ser tan simple como se pueda, y no más.

Sorprendentemente, hacer las cosas sencillas cuesta más trabajo que hacerlas complicadas. Normalmente un diseño o código suele ser fruto de varias tentativas y aproximaciones hasta que logramos una solución que cumple todos los requisitos. Inicialmente nos preocupamos de que sea eficaz (es decir que haga lo que tiene que hacer) y vamos añadiendo elementos hasta que lo conseguimos. El paso hacia la sencillez es posterior y deliberado: consiste en examinar el diseño y simplificar y quitar elementos innecesarios hasta que ya no podemos quitar ninguno.

Blaise Pascal se despedía en una de sus célebres cartas con una disculpa: "Si hubiera tenido más tiempo hubiera escrito la carta más corta". Lo mismo digo: ojala fuera capaz de decir lo mismo con menos palabras.