Analogías y desarrollo de software III (fin)

Crónicas de Islandia I: GPS

Llegamos la última parte de esta serie sobre analogías e informática. En este post voy a exponer las metáforas y modelos mentales que suelo encontrar asociados a sistemas informáticos y su evolución. Esta es la parte más “avanzada” de la serie así que si no te interesa el mundillo como profesional, probablemente puedes ahorrarte el ladrillo.

Paso a producción como proceso explosivo

Este modelo mental trata las entradas a producción de un sistema como algo inmediato y de alto impacto. Eso significa que seguramente estamos ante un proyecto waterfall (en cascada) que incluye montones de elementos nuevos y poco o nada probados (procesos, sistemas, integraciones, herramientas…).

Entre los sinónimos encontramos “Big Bang“, lo cual resulta irónico al pensar en la astronómica cantidad de tiempo que se necesita dejar transcurrir entre un Big Bang y un Universo habitable. Y eso sin pensar en los ajustes.

Normalmente este proceso falla en proyectos grandes. A veces incluso antes de llegar a intentarse, dado que impacta en demasiadas áreas a la vez como para que todo el mundo esté de acuerdo en una fecha y funcionalidad. Por eso aunque este modelo se usa, acaba mutando a un proceso de paso a producción incremental o algo intermedio, pero en cualquier caso mucho más humilde en el impacto producido.

La ventaja de este modelo es que todo el mundo está encantado con la idea de no tener que hacer nada hasta un día concreto: nada de formación, evolucionar el producto, recabar feedback, pensar… Por eso es fácil que el cliente lo acepte (o exija) y el proveedor lo ofrezca. Y por eso es fácil que fracase: no es una solución, es una patada adelante a un conjunto de problemas que acabarán apareciendo igualmente.

Seguramente ahora estés pensando que has visto una buena entrada en producción de este tipo y que estoy exagerando. Puede que tengas razón, pero deberías pensar si ese proyecto que recuerdas no habría tenido mucho mejor resultado si se hubiese abordado como un desarrollo incremental, iterativo, con mejoras continuas de los procesos y usuarios involucrados en aprender y dar feedback. De eso va la agilidad, el Lean, los MVP… así que vuelve a pensar.

El entorno tecnológico como ecosistema

Hace unos años pensaba que este modelo mental estaba más extendido pero he podido comprobar que aunque se usa mucho por parte de técnicos, no parece tan habitual entre otros perfiles de la profesión.

La idea es que, al igual que una selva o una cueva son sistemas con ciertas características, límites, fauna y flora, los sistemas informáticos son entidades vivas de un entorno con ciertas características y límites que funcionan unidos. Lo más interesante de este sistema es que instintivamente se entiende que hay que mantener un equilibrio entre las partes para que el ecosistema no se derrumbe. Y que cualquier modificación del mismo requiere ciertos cuidados y no pueden realizarse a gran escala y de una sola vez si queremos conservar el ecosistema.

Podemos ver las diferentes piezas de hardware, software y servicios como elementos de ese ecosistema y podemos entender fácilmente la necesidad de vigilarlo y cuidarlo, interviniendo regularmente para mantenerlo sano.

El único “pero” que le veo a este modelo es que se le puede coger cariño al ecosistema o pensar que es un ente endeble que no debe cambiar. Y eso puede hacernos difícil ver cambios necesarios. Por ejemplo, aunque vivamos en un desierto y estemos perfectamente adaptados al mismo, quizá sería bueno evolucionar a algo diferente. Y aunque estemos muy cómodos en nuestro bosque, deberíamos empezar a cambiar algo para adaptarnos a la glaciación que viene.

Evolución y versiones de software

La Evolución es una idea que apenas tiene 300 años, y en mi opinión el público en general aún tiene (y seguirá teniendo) problemas para entenderla debido quizá a que los seres humanos tenemos capacidades muy limitadas para entender los efectos acumulativos, los periodos mayores a un puñado de años y las matemáticas.

Aun con esa falta de entendimiento la idea es seductora, potente, y se emplea para hablar de modelos de desarrollo incrementales, MVP (mínimo producto viable) y versiones de producto.

La idea es que una evolución del software, una nueva versión, un… evolutivo, es una versión diferente, mejor y más adaptada del software que tenemos en manos actualmente. En realidad la idea es fácil de transmitir y en general creo que funciona bien. Sin embargo la analogía no es correcta del todo y eso puede llevarla por un mal camino.

Se supone que la Evolución se produce poco a poco a lo largo de mucho tiempo, mientras que los desarrollos evolutivos son conjuntos de cambios normalmente bastante mayores en relación y que se introducen a saltos. Me recuerda mucho a la disputa sobre la que leía hace casi 2 décadas en los libros de Richard Dawkins acerca de si la evolución era “continua” apoyada por él mismo o si era “a saltos” apoyada por Stephen Jay Gould.

En resumen, aunque creo que la idea está bien, no parece que realmente llegue muy lejos por los problemas que tiene entender la Evolución, con lo que aunque se usa mucho esta analogía, me temo que su utilidad es muy limitada si no tenemos un interlocutor adecuado.

Selección sexual y testing A/B

Ahora que se ha puesto de moda el testing A/B, estoy empezando a ver el uso de la analogía con la selección sexual. Si entiendes como funciona esta técnica y qué es la selección sexual, verás la relación evidente y podrás anticipar que es una técnica interesante para evolucionar el software (ver analogía anterior: Evolución). En otro caso, me temo que no tengo espacio suficiente en este artículo para tratar sobre ambos conceptos por lo que recomiendo unas horas de navegación y estudio.

En resumen, la idea del A/B testing es que si entiendes cómo funciona la selección sexual (organismos compitiendo entre sí por reproducirse con una pareja y producir descendencia de características similares) puedes ver como conecta eso con la idea de poner 2 versiones diferentes de un mismo software con características similares y pequeñas diferencias para que compitan por un mismo grupo de usuarios. Al cabo de algún tiempo y muchos usuarios, tendremos una tendencia clara (en el mejor de los casos) que nos indicarán qué característica merece sobrevivir y evolucionar en nuestro software.

Esta analogía no suele ser necesaria para explicar los conceptos, pero si para explorar las limitaciones de la técnica. Lamentablemente requiere de conocimientos sobre Evolución, que como he comentado no son demasiado comunes, por lo que esta analogía y sus críticas solo la estoy viendo en entornos profesionales de discusión sobre la técnica, no en comunicaciones cliente – proveedor.

Como nota adicional es interesante ver que esta técnica se ha copiado de otro contexto, el de márquetin de productos si no he entendido mal, lo que resulta irónico: alguien entendió la similitud entre ambos mundos y decidió emplear la técnica, como Henry Ford en su día con la cadena de montaje…

Y hasta aquí llegamos con esta serie de artículos sobre analogías y software.

Analogías y desarrollo de software II

Crónicas de Islandia IV: Consejos a viajeros

En el post anterior comentaba algunas analogías comunes en informática. En este post voy a comentar algunas un poco más avanzadas sobre desarrollo de software pero también muy comunes.

Desarrollo de software como construcción de objetos físicos

Aunque insisto en que el desarrollo es un proceso de diseño y no de construcción, esta analogía es un clásico y te encuentras la idea en casi todos lados.

Se considera que construir una aplicación es una actividad similar a construir un edificio o un avión. Se necesitan arquitectos, montones de documentación y maquetas, ingentes cantidades de dinero y numerosas cuadrillas y material especializado. Además se considera que el diseño es barato y la construcción cara. Por último este modelo mental invita a pensar en soluciones que permanecerán más o menos invariables a lo largo de muchos, muchos años.

Lo más importante que hay que decir sobre este modelo es que está completamente equivocado. Si lo veo asomar en un proyecto, sé que vamos a tener problemas, que el producto será inferior a lo que podría ser y que va a costar mucho más de lo que debería. Pero al menos es un modelo que puedes usar para comunicarte con el cliente. Y si demuestras que sabes más de construcción (estilos, historia, materiales, anécdotas sobre grandes obras…) que el interlocutor y haces una intensa labor de comunicación y pedagogía puede que consigas sacar el proyecto adelante en unas condiciones decentes. Pero en cualquier caso es un modelo terrible.

Desarrollo de software como viaje

En este modelo mental, el desarrollo es como un viaje. Sabes de donde sales, marcas un destino y estableces un presupuesto, tiempo y recursos a emplear. Con esos parámetros estableces los parámetros del viaje: Bussines, low cost, escalas, duración, fechas, extras…

Lo bueno de este modelo es que se entiende que cambiar de ruta o destino puede ser costoso o barato en diferentes etapas del viaje. Que un medio de transporte (tecnología, recurso) puede ser necesario en algunos casos. Que habrá retrasos en algunas etapas y eventos inesperados (tormentas, retrasos acumulados, accidentes). Pero creo que lo más interesante es que ofrece la posibilidad de aprender durante el viaje y cambiar de rumbo o quedarse en una etapa concreta si el cliente lo considera útil.

Lamentablemente este modelo mental no es muy común y tiende a despreciarse al parecer menos “definido” (lo cual es una mera percepción, pero es difícil convencer a alguien sin experiencia de esto), pero puede dar mucho juego si entendemos que algunos clientes quieren un viaje al África salvaje (grandes riesgos, incógnitas, mucho que ganar, caro…) y otros meramente quieren un crucero con todo pagado por el Mediterráneo (barato, en masa…). Con esta analogía entendemos que diferentes proyectos deben gestionarse, venderse y realizarse de manera radicalmente diferente. Que no hay una bala de plata.

Desarrollo de software como guerra

En este modelo mental el cliente es el enemigo y cada proyecto es una campaña militar que solo puede acabar en victoria o muerte. Es habitual encontrar este modelo en muchas grandes empresas, tanto como cliente, como proveedor. Y en esos entornos hostiles (las grandes empresas tienden a convertirse en reinos de taifas, grupos de presión e interés, cada uno con sus rencillas) es fácil transmitir esta visión y creérsela.

Lo interesante de este modelo es que es divertido. Me explico: Poder lanzar una ofensiva bélica contra el frente enemigo y conquistar cada una de las ciudades importantes en tiempo record y sin bajas, es mucho más interesante que poder entregar el módulo de gestión de inventario de una factoría de tornillos en tiempo y coste. Cada paso a producción produce héroes y gloria en lugar de trabajadores quemados y resultados mediocres. Y el fin de proyecto significa la vuelta a casa con medallas y desfile, en lugar del papeleo de cierre de esa web de abogados que acabamos de terminar.

La verdad es que este modelo solo me parece útil para motivar a la gente a continuar trabajando, o como forma de tratar con un cliente/proveedor realmente malo. Por eso, si necesitas recurrir a él significa que, o bien estas en un contexto de trabajo pésimo, o bien te estas convirtiendo en un sociópata muy competitivo que busca ganar por encima del resultado a largo plazo del proyecto. En cualquier caso, el uso de este modelo es una señal bastante clara de que deberías buscar otro lugar de trabajo lo antes posible.

Continuará…