El nombre del principio es el acrónimo del inglés Keep It Simple, Stupid o Keep It Short and Simple. El sentido, se puede imaginar. Es en realidad la aplicación de lo que se conoce como La Navaja de Occam (Ockham’s Razor) aplicado a la informática. Todo se basa en una simple premisa: “dadas dos soluciones a un problema determinado, la más simple es probablemente la correcta”.
Aplicado al mundo del desarrollo de software, lo que se conoce como el principio KISS, implica resolver los problemas del modo más sencillo posible y posiblemente ésta sea la mejor solución.
Código
Desde el punto de vista del código tiene más implicaciones a parte de la simplicidad:
- Un código más simple es más sencillo de mantener, lo que ahorrará tiempo en el futuro.
- Además, será más sencillo de comprender por cualquier persona que entre en el equipo de desarrollo.
- Cuesta menos de escribir
- Menos lineas equivalen a menos bugs, lo que significa código de mayor calidad
Gestión de proyectos
Pero todo esto carece de sentido si desde no se tiene también en cuenta desde el nivel de gestión de los proyectos de software. Es estupendo pensar en miles de funcionalidades para un producto pero ¿qué sentido tienen? Primero habrá que hacer lo más simple para luego ir añadiendo más cosas a una base sencilla y comprensible.
Hay que construir software sobre una base sólida y unos requisitos simples y concretos. Esto permitirá desarrollar unas funcionalidades simples y robustas en menos tiempo y una vez el producto tiene cara y ojos, se pueden ver las carencias y se pueden encontrar nuevas posibilidades.
Pensar en cientos de funcionalidades, además tiene otras implicaciones menos obvias:
- Tests de usuario menos frecuentes pero mucho más complejos y largos.
- Bugs más difíciles de encontrar y de solucionar.
- Time-To-Login (tiempo entre que se empieza el desarrollo hasta que se tiene una primera release) mucho más alto.
Muchas de las metodologías ágiles se basan en parte en este principio para desarrollar un software evolutivo en vez de crear gran cantidad de especificaciones y documentos que pueden tardar años en implementarse y meses en integrarse.
En resumen, antes de escribir un método, piensa si no lo estás complicando demasiado y antes de añadir un requisito a una release… piensa si realmente es necesaria en ese momento. Recuerda: KISS.
Aunque ya abandoné la programación hace un tiempo, por cosas de la vida me vi al frente en mi trabajo de un proyecto “mastodontico”. La aplicación, que llamaremos X, tenia tal cantidad de requisitos y funcionalidades (concretas y abstractas) que se tardó un año en pasar de powerpoints (si, nada de UML) a programar la primera linea de código, tras vicisitudes y otro año se logró desarrollar un front-end que permitia poco mas que autenticarse, en este punto cogí el proyecto, y desde mi ignorancia, llegué a la misma conclusión de todos los procesos “agile”, simplifiquemos al máximo y centremonos en desarrollar UNA funcionalidad que sirva al cliente, el proceso paso de estado catatónico a pronóstico reservado (una gran mejoría) en seis meses logramos la primera release (a los 2,5 años de proyecto y casi 100.000 € perdidos, digo invertidos) parecia que reflotaria, en este punto deje el proyecto y ahora vuelven a pedir 1001 funcionalidades, con lo que veremos como acaba.
Mis conclusiones:
- Gestionar proyectos de desarrollo de SW debe hacerse por expertos en ese campo (y no por cualquier gestor)
- La filosofia KISS, AGILE, como la llamemos, es decir hagamos algo que al menos haga UNA puñetera cosa y funcione bien con el menor coste posible es la unica forma de llegar a un proyecto que devuelva la inversion (ROI > 0). Por supuesto del bueno, bonito y barato hay que renunciar a una cosa, en este caso seria bueno y barato (pero no bonito, ya que hace UNA cosa no las 1001 que sueñan nuestros jefes)
- La cadena Analista Funcional – Analista Tecnico – Programador NO FUNCIONA, ni funciona el concepto de “POOL DE PROGRAMADORES”, si el programador no sabe que está programando, es decir la tematica de la aplicacion no se la “estudia a fondo”, mal vamos, muy mal especialmente en proyectos largos.
En fin, estas son mis desventuras… (que conste que yo no quise dirigir ese proyecto, me obligaron…)
@Anonimo.Q Muchas gracias por tu comentario. Creo que cada vez hay más gente que se da cuenta de que hacer proyectos de software no es un proceso parecido a construir edificios por lo hay que adaptar los modelos a cada campo. Los analistas funcionan pero no para crear una gran pelota caliente que “pasa” a los programadores como si fuesen autómatas: deben conocer el campo de trabajo de la aplicación así como tener una diversidad de conocimientos y recursos para, con el apoyo de analistas/coordinadores o como se les quiera llamar, llevar la aplicación a buen puerto, poco a poco. No creo que ningún proyecto mastodóntico de software haya terminado bien por más UML que se hicieran (o Powerpoints, o reuniones).
Solamente estoy un poco en desacuerdo en lo del gestor de proyectos. Un buen gestor puede gestionar cualquier cosa que se le ponga delante, delegando en las personas de confianza que dominen las tareas a realizar, pero demasiadas veces estos gestores pretenden saber más que los expertos, dinamitando su motivación y confianza en el proyecto.
No estoy totalmente en desacuerdo con lo del Gestor, pero desde mi humilde punto de vista profano en la materia, el problema de un gestor “no experto” es que tiene que lidiar con los “capeos técnicos” que le hacen también ciertos programadores que por vagancia, desidia o falta de amor a su propio trabajo son los primeros dinamiteros dentro del proyecto, no queriendo saber nada a nivel funcional y exigiendo esos millones de PPTs y UMLs para justificar su falta de ganas por aprender del tema que va la aplicación…
No generalizo, ya sabemos que habrá gestores que dinamitan proyectos como citas, yo conozco a más de uno, lo mejor sin duda es tener buenos programadores… sin duda.
Bueno, eso es cierto pero sigo pensando que un gestor realmente bueno debe saber dónde están sus límites. Pero este es un país de pandereta y castañuela y extrañamente parece que muchas veces los menos capacitados pero más atrevidos acaban siendo gestores de un equipo que los toma por el pito del sereno y cualquier mindundi se piensa que sabe de todo.
Para hacer bien un desarrollo los programadores deben conocer de primera mano el uso que se va a hacer de la herramienta en vez de pedir diagramas y powerpoints. Documentar está bien pero la fluidez de la comunicación entre el equipo de desarrollo y el cliente final es fundamental.
Ah, y por no decir que en esta comunicación muchas veces los “gestores” añaden cosas de su propia cosecha con la excusa de que el cliente “lo necesita”, aumentando la complejidad y reduciendo la calidad del producto final.