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.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s