YAGNI, KISS, OCKHAM. Elige tus batallas

Son muchas las teorías, técnicas y principios que nos demuestran que en ciertas ocasiones resulta beneficioso mantener las cosas de forma simple. Complicarse, por más contradictorio que resulte no es complicado, y en muchas situaciones la pérdida de valor y el coste de oportunidad asociado a estas complicaciones pueden resultar muy costosas.¿Opaca esto de alguna forma a la ingeniería del software? ¿A la gerencia de proyectos de tecnología? (…)

Para responder estas interrogantes es necesario evaluarlas al menos desde las siguientes dimensiones: contexto del proyecto, tiempo del proyecto, valor de negocio y entorno tecnológico – son muchas realmente, pero éstas son un buen comienzo – . Los principios YAGNI (You Ain’t Gonna Need It), KISS(Keep It Simple, Stupid!) y la navaja de OCKHAM nos sugieren algo muy valorado en estos días: centrarse en el valor de negocio presente. En estos enfoques, la premisa pasa por reconocer que el análisis y depuración de los requisitos para muchos tipos de proyectos de tecnología es un proceso de revisión continua e inexacta: los clientes no saben lo que quieren hasta que lo ven. Esto es una realidad muy latente, sobre todo por lo turbulento que se encuentran los mercados y la economía mundial producto, en parte, del avance tecnológico desorbitado en estos últimos años. Una Startup, por ejemplo, que quiera surgir – y debe hacerlo generalmente en semanas – no puede estar meses analizando y buscando la mejor solución tecnológica, porque cuando lo haga, quizá ya sea demasiado tarde. Pero, y aquí debemos hacer un paréntesis importante, esto tampoco significa lo contrario: ofrecer soluciones carentes de calidad. No. Significa que la solución vaya creciendo paulatinamente en el tiempo junto con las necesidades cambiantes y el soporte administrativo-financiero que se tenga en cada momento.

Existen visiones de negocio que apoyan que una idea debe ser lanzada cuanto antes, independiente a los errores que pueda tener. Tal es el caso de Stephen Kaufer, CEO de Tripadvisor, quien comenta en [1] que siempre tratan de probar nuevas cosas y lo hacen en tiempo récord. No porque tenga un equipo de personas infrahumanas desarrollando, sino porque aceptan de antemano que la solución perfecta es la que sale a producción cuanto antes y mejora con el tiempo. En sus palabras: «Tardar nueve meses en lanzar una idea de producto es ridículo(…) en muchas ocasiones ese esfuerzo extra, ese tiempo añadido que se dedica para hacer perfecta la solución no es necesario, porque nadie se da cuenta. Los clientes no se dan cuenta. Y el tiempo que se dedica a eso no se destina a la siguiente campaña importante, al siguiente desarrollo, a la siguiente característica de peso del producto(…)»; otras visiones desde el punto de vista tecnológico sugeridas por Sandi Metz en [2] nos recuerdan que cuando se tiene un equipo de analistas y diseñadores de software expertos, se pueden anticipar los problemas de forma inteligente, haciendo una solución simple a la vez que robusta y preparada para escalar en el futuro.

Seguir los principios YAGNI, KISS Y OCKHAM no debe considerarse como una alternativa a la ingeniería del software, deben ser parte de ella, y el hecho de mantener las soluciones con simplicidad en todo momento garantiza una relación coste-beneficio saludable para todo el ámbito del proyecto. Han quedado atrás los días en donde salir a producción con errores era mal visto, han quedado aún más atrás los días en donde se esperan soluciones perfectas en un solo ciclo de trabajo. Estamos en medio de sistemas complejos adaptativos. Es una nueva realidad, hay que asumirla: si bien el software no se desgasta sino que se deteriora[3], esto no solo aplica para software en producción. Se deteriora desde el minuto uno del inicio del proyecto. Por ello un equilibrio entre diseñar soluciones escalables de forma inteligentemente simple tal como sugiere Metz, junto con la visión de Kaufer de probar en producción cuanto antes una idea de negocio, apostando por la simplicidad y aceptando que no será perfecta y que tendrá errores, es quizás uno de los pilares fundamentales en que debe basarse la gerencia de tecnología actual.

Recuerdo que una oportunidad acudí a una conferencia acerca de nuevas apuestas simples para soluciones complejas usando filosofía ágil. La conferencia estaba rodeada de polémica, pues la mayor parte de la audiencia estaba formada por gerentes de proyecto de muchos años de experiencia, muy tradicionales y estrictos. El presentador comentaba como en un proyecto que llevaba mucho retraso y que era imposible terminar a tiempo, tomaron una decisión simple y consiguieron sacarlo adelante. Como lo que realmente faltaba era una interfaz gráfica para poder operar con la base de datos, se tomó la decisión de salir a producción sin ésta, y mientras se desarrollaba, los usuarios finales ejecutarían scripts directamente sobre la base de datos. Todo un <<sui géneris>>, pues. Podrán imaginarse el silencio de leones en la sala que prosiguió a esta idea. Era una de esas ideas que al principio chocan contra todo pronóstico, pero que cuando se digieren y meditan lentamente, están cargadas de pragmatismo, razonamiento y lógica. Si los usuarios finales son capaces de manejar tablas pivote de Excel, ¿por qué no manejarían bases de datos? ¿ Por qué peder valor de negocio y aumentar el coste de oportunidad por miedo a el pase a producción? Al final, una de las más importantes ideas que me lleve de esa conferencia y que ha marcado y dictado el rumbo de hacer las cosas en mi vida, fue aquella con la que culminó el presentador en donde comentaba que generalizar un buen ejemplo es equivocarse siempre, y que nunca debemos enamorarnos de una sola idea y de una sola forma de hacer las cosas. ¿Cómo saber cuando usar enfoques simples entonces? preguntó alguien de la audiencia. Elige tus batallas, culminó el presentador.