Analogías y desarrollo de software I

Crónicas de Islandia VI (Final)

Este post continúa la reflexión sobre analogías, modelos mentales y el desarrollo de software (ver 1, 2 y 3). Una vez repasado la importancia que para mí tienen estos instrumentos, voy a comentar algunas analogías habituales, que son fáciles de encontrar en el día a día del desarrollo y la consultoría, tanto por parte del proveedor como del cliente.

Estas analogías son útiles en determinados contextos y dañinas en otros como cualquier otra herramienta, pero sobre todo es peligroso llevarlas demasiado lejos ya que es fácil olvidar que la realidad y el modelo son dos cosas diferentes.

Empezaremos por las fáciles y luego iré incrementando la complejidad de estas.

Carpeta

Esta metáfora está tan arraigada que ya olvidamos que es una metáfora y por ello nos negamos a tratarla como lo que es: una forma de relacionar ciertos datos y tratarlos como una unidad para ciertas operaciones (seguridad, copiado, búsqueda…). A día de hoy muchos sistemas emplean otras metáforas para lo mismo: etiqueta, sala… pero una enorme cantidad de usuarios, incluso técnicos son incapaces de entender que se trata esencialmente de lo mismo bajo otro nombre si alguien no se lo señala.

En general esta metáfora es dañina porque no permite hablar de contenedores y relaciones complejas de forma separada lo que lo convierte en una losa a la hora de evolucionar la forma de trabajo de la gente que está anclada en este modelo de pensamiento.

Es el caso más claro en que el modelo se considera la realidad.

Papelera

La metáfora de la papelera de reciclaje me parece bastante útil aun, ya que permite explicar al usuario lo que sucede con la información que se elimina como si fuera un objeto físico y establece un mecanismo de retención que permite cometer errores sin consecuencias. No le veo ninguna contraindicación, salvo el que no sirve para nada más (que no es poco).

Ratón

Hace unos días mi hija de 5 años me preguntó que qué era aquello que tenía en la mesa. Le respondí que un ratón de ordenador. Y a continuación me preguntó que por qué se llamaba así. Al tratarse de un modelo inalámbrico, tuve que sacar uno de cable del armario de los trastos para explicárselo correctamente.

Este nombre tenía sentido hace algunos años pero a día de hoy va a seguir el camino de los disquetes como icono de “guardar” volviéndose inútil en un mundo cada vez más orientado al uso del dedo y el stylus. Además no transmite ninguna información sobre la utilidad del objeto.

Así que actualmente considero que esta metáfora está obsoleta aunque originalmente cumpliese bien la función de disponer de nombres reconocibles para tecnologías punteras.

Virus y Antivirus

El concepto de virus es muy útil para transmitir la idea de peligro contagioso. Además es una analogía biológica lo que permite empezar a hablar de los sistemas informáticos como algo vivo, como organismos (otra analogía).

Sin embargo la analogía pierde un sentido importante en el mundo actual: los programas maliciosos actualmente no carecen de propósito y en la mayoría de los casos son más parecidos a los parásitos y los depredadores que a una “mera” molécula de ARN.

Posiblemente esta metáfora siga con nosotros durante mucho tiempo.

Firewall

El comparar un “muro de fuego” con una máquina que deniega o permite canales de comunicación para determinadas direcciones y protocolos, me parece un desastre.

De acuerdo, es relativamente fácil entender que nos protege de ciertas agresiones denegando el acceso, pero en mi opinión da una falsa imagen de solidez y seguridad al pensar en un muro que requiere de fuerza bruta para ser superado.

Creo que simplifica demasiado algo muy complejo y delicado, lo que puede provocar problemas de comunicación, como que se piense que es algo pesado, costoso e inamovible, o que tener uno es garantía suficiente contra intrusiones. Pero todo esto es solo una opinión, claro.

Nube, cloud

No podía faltar en esta lista uno de los términos de moda de los últimos años. La idea de algo etéreo, gigantesco y omnipresente en cualquier lugar del planeta me parece muy buena, y dado lo arraigado del concepto de “subir” y “bajar” cosas de internet, me parece coherente. Pero ahí queda la cosa. La nube es la red de ordenadores de otro, ni más, ni menos. Y no solo contiene agua, hay todo un universo de servicios increíbles en ella.

De todos modos me gusta mucho a nivel de márquetin, y durante una temporada estuve usando esta metáfora de forma habitual para explicar como Azure y Office 365 ofrecen una gama de servicios para todo tipo de empresas: una nube para “regar” tu negocio, que podía aportar más o menos agua en función de las necesidades del cliente (flor, árbol, bosque…). Era una imagen muy visual que transmitía crecimiento y limpieza.

Continuara…

Aníbal el gestor de proyectos

Mi padre siempre tuvo mucho interés en la figura de Aníbal Barca, el general cartaginés que puso en jaque a la pujante república romana en la segunda guerra púnica hace casi 2000 años. Me contaba como partió desde el norte de África, atravesó la península Ibérica reclutando tropas y asegurándose una línea de suministros, atravesó los Alpes con elefantes de guerra cuando nadie lo imaginaba posible y como puso en jaque a todo lo que Roma pudo echarle encima durante años de sembrar el terror en el corazón de la República… para ser finalmente fue derrotado por un general enemigo (Escipión el Africano), con un plan lo suficientemente audaz y quizá por la falta de recursos que le provocaron los propios gobernantes cartagineses.

Aníbal fue una de esas personas que pudo haber cambiado la historia del mundo a lo grande. ¿Imaginas un mundo en el que el Imperio Romano no hubiese existido? Quizá ahora estaríamos hablando una variante del persa, la Iglesia Romana no habría existido y sabe dios qué clase de cultura tendríamos en Europa.

En inferioridad

Y pensando en Aníbal y en sus estrategias de batalla, no puedo dejar de ver ciertos paralelismos con los proyectos de desarrollo de software y una pregunta que me hago constantemente: ¿Cómo llevas a buen puerto un proyecto con menos recursos de los necesarios?

Una de las batallas de Aníbal, la batalla de Cannas o Cannae, es uno de los mejores ejemplos de cómo vencer a un enemigo superior en número aprovechando el conocimiento del terreno y planteando una estrategia que incluye conocer las características de tus tropas y ejercer el liderazgo de forma directa.

En esa carnicería, Aníbal logró utilizar las elevaciones del terreno, el curso del rio Ofantos (el entorno y circunstancias) y la variedad de fuerzas que tenía a su disposición: un ecléctico conjunto de caballería númida, infantería pesada cartaginesa e infantería ligera ibérica (el equipo). Planificando la batalla al milímetro (la planificación) y usando todo lo aprendido y refinado en batallas anteriores (la experiencia), supo leer la estrategia romana por adelantado (prevención) y acertó a situarse en el centro de todo el meollo, es decir en la peor parte, para poder infundir valor y mantener el orden evitando así el colapso previsible de su línea de batalla (liderazgo, control y un par de huevos) en circunstancias normales.

No rompas la línea, soldado

La línea de batalla es el nombre que se le da al “muro” de soldados que plantamos frente al enemigo y mantenerlo entero evita que el enemigo divida nuestras fuerzas en dos o más grupos. Una ruptura en nuestra línea impedirá la coordinación entre grupos aislados, debilitando a las unidades por falta de apoyo y facilitando que se nos rodee convirtiéndonos de facto en pasto de buitres. Por ello jamás debe (siempre hay excepciones) romperse la línea pues la única opción es la retirada (total, o para recomponer la línea). O el exterminio, claro, que en este caso se produjo en el bando romano gracias a la unidad del frente cartaginés.

No rompas la línea, developer

En desarrollo de software, también existe esa línea de batalla, y la compone cada uno de los miembros del equipo. Si alguno de los miembros del equipo se retira de un proyecto para trabajar en otro, habremos dejado un hueco en nuestra línea. Uno que debe ser cubierto por un perfil similar, o que debe ser cerrado reduciendo la longitud de nuestra línea.

Esto se traduce en que si tenemos un número de desarrolladores pequeño, nuestra línea, al alargarse para abarcar más, será fina, y por tanto débil, incapaz de soportar una ampliación o cambio en el proyecto (o el aumento de proyectos). Por otro lado, si nos empeñamos en mantener la línea con cierto “grosor”, el aumento de alcance de un proyecto o del número de proyectos acabarán por rodearnos, o colarse por nuestros huecos. Y si el trabajo nos rebasa por los flancos tendremos una versión de la carnicería de Cannas en versión desarrollo de software. En caso de que nuestra línea deje huecos, nos dividiremos, perderemos la comunicación, nos aislaremos y lo más probable es que aunque algunos puedan huir, el resto acabe siendo pasto de los buitres de un proyecto fallido.

Como última reflexión, normalmente toda derrota en el campo de batalla se traduce en dolor, sangre, soldados desertando, generales que se retiran antes del previsible final, y algún que otro héroe que morirá igualmente. Además de los castigos ejemplares para los supervivientes, porque hay que dar ejemplo :-(. Es curioso cómo pueden llegar a parecerse el desarrollo de software y las batallas de la antigüedad.

Pensando: Analogías, símiles, metáforas, copia, innovación y comunicación

WP_20131102_040

Las analogías son una herramienta mental muy potente. Cuando uno necesita pensar en nuevas soluciones, innovar un sistema o necesita entender y explicar algo, las analogías y sus parientes lo símiles y metáforas se muestran como una de las herramientas universales. Este artículo recoge algunas ideas al respecto y, por aligerar el texto, en general me referiré a todos estos elementos indistintamente como “analogías” aunque no sea ortodoxo.

Henry Ford copió la idea de la cadena de montaje de un matadero porque entendió el parecido de un negocio de despiece de animales y uno de montaje de coches. Ford estableció una analogía entre la sala de despiece de un matadero y la fábrica. Y entre el cerdo y el coche. Y con eso como base, pudo innovar en un negocio multimillonario y entrar en la historia empresarial como genio de la innovación y la gestión.

Sigmund Freud usaba un símil: el del cerebro visto como una máquinas de vapor. Lo usaba para explicar su modelo teórico del funcionamiento de la mente indicando que la presión en el inconsciente se aliviaba tarde o temprano mediante válvulas de escape. Así podía explicar algo abstracto a una audiencia menos teórica sin necesitar conceptos y términos complejos.

Desde la antigüedad todo tipo de autores han usado metáforas para transmitir ideas, tanto a analfabetos como a nobles ilustrados; en algunos casos como forma de manipulación (retórica) y en otros como forma de comunicación de ideas (parábolas, proverbios, fábulas…). La Biblia está llena de ellas (el pastor, el rebaño…) y parece haber funcionado bien durante 2000 años. También todas las mitologías rebosan de ellas (la serpiente, el lobo, el paraíso perdido…) y al menos las locales parece haber pervivido hasta nuestros días en diferentes formas (cuentos, cine…).

Las analogías y sus parientes, son herramientas útiles para pensar de forma diferente, y para transmitir ideas “extrañas” o nuevas, como la relatividad general, la evolución de las especies o el desarrollo ágil. Para las personas que no disponen de información o experiencia sobre un tema estas herramientas facilitan una introducción. Para las que han estado trabajando en un problema, facilitan identificar una solución que podría aplicarse desde otro área. Para las que necesitan transmitir una idea compleja es una herramienta que permite iniciar la conversación con públicos de conocimientos dispares.

Por supuesto estas herramientas tienen sus propios problemas: a menudo se llevan demasiado lejos como cuando se piensa que el cerebro es un ordenador y funciona igual, o solo son superficialmente útiles como cuando se establecer una analogía con el cáncer para provocar miedo y rechazo a un tema. Además las analogías necesitan de la existencia de una cultura común, un pool cultural, para que sirva al propósito de comunicar. Por ejemplo, Freud no habría podido emplear la máquina de vapor en sus exposiciones si la audiencia no hubiese conocido el ferrocarril, e imagino que los discursos del Cristianismo debieron tener mucha más fuerza en sociedades duras con abundancia de pescadores y pastores.

Sea como fuere, estos elementos son útiles para establecer un modelo mental o “marco” (framework) sobre el que se puede empezar a trabajar en nuevas soluciones o comunicar algo complejo. Y eso los convierte en algo tremendamente útil cuando tu trabajo se basa en trasladar y entender ideas complejas, dar soluciones técnicas sofisticadas y coordinar personas con diversidad en la cultura y experiencias. Por lo tanto, como consultor tecnológico, necesito usarlas en mi día a día de forma constante y muy especialmente en los proyectos de SharePoint y Office 365 que son servicios y sistemas con una complejidad y extensión abrumadoras.

En general el uso de estas herramientas no es algo deliberado y consciente sino que más bien surgen de forma natural durante la comunicación con el cliente, cuando trato de encontrar una forma de comunicarme con él de forma efectiva y empiezo a conocer su cultura un poco más, aunque a menudo las analogías y metáforas que usamos no se ven como tales y a veces llevan a nuevos errores de comunicación (“dijiste que“, “pensaba que“). En muchos casos veo además un problema adicional: modelos mentales, marcos de trabajo erróneos u obsoletos, que requieren un esfuerzo extra de comunicación para detectarlos y poder dar lo que en ese modelo mental del cliente se considera una buena solución y no lo que yo considere “buena solución”.

Como puede deducirse del párrafo anterior, en mi opinión, las soluciones “técnicas” no son soluciones de tipo “blanco y negro”. No existen “buenas prácticas”, sino “prácticas adecuadas en el contexto”. Y es ese contexto el que necesito entender y con el que debo trabajar para dar buenas soluciones que sean entendidas como tales. Obviamente lo siguiente que se desprende de esto es que para mí, el problema de tratar de dar una solución al cliente es principalmente un problema de comunicación. Pero entiendo que no todo el mundo lo vea así.

Lo siguiente que se desprende de estas ideas es que si para dar una solución técnica se necesita comunicación y para la comunicación se necesita una cultura común, entonces como cliente, para obtener una buena solución a mi negocio necesito que mi socio tecnológico sea eso: un socio. Es decir: comunicación constante abierta y directa y que quiera entender mi negocio. Si voy cambiando de proveedor constantemente o si no me implico en la comunicación con mi proveedor (añadiendo capas de intermediarios y procedimientos que reemplazan la comunicación real), difícilmente voy a tener un buen servicio.

Llegados a este punto puede que algunos empiecen a ver la relación entre estas ideas y el Manifiesto Ágil, pero dado que pretendo seguir escribiendo sobre modelos mentales, quiero cerrar aquí el post dejando el siguiente resumen:

Todos tenemos nuestra propia cultura y experiencias. Para resolver problemas necesitamos comunicar estos modelos mentales de forma que todos resolvamos el mismo problema. De ahí que en mi opinión las mejores soluciones surjan de equipos (cliente-proveedor) con mucha experiencia e interés en comunicarse mientras que las peores soluciones surgen de equipos con poca experiencia (poco variada, poco tiempo) y que dan por hecho que la comunicación se limita a un documento y reuniones de seguimiento.

Continuará…