En el año 2001 tuve la suerte de conocer a una persona que trabajaba en uno de los mayores fabricantes de software del mundo. Cuando me dió su tarjeta de visita, no pude sino observar estupefacto su título: era Evangelista Técnico. Me quedé siberet. Yo era un miserable Analista Programador, y eso de ser Evangelista me parecía lo más de lo más.

Con la edad, he llegado a asumir como algo normal la existencia de toda clase de Evangelistas; no en vano, el mundo de la informática está lleno de parábolas que intentan explicar, hacer ver, abrir los ojos, o simplemente, adoctrinar, qué es o qué deja de ser un proyecto de desarrollo de software. La mayoría de las veces, se usan para que alguien que paga por un sistema entienda que va a tener un retraso en un proyecto, un aumento del precio, la imposibilidad de lograr ciertos resultados, o todas ellas.

«En peores plazas hemos toreao»

Así que, iluminado por el trabajo ingente de Antii Aarne y Stith Thomson, me embarco en la romántica tarea de recopilar fábulas y folclore tradicional de los que vivimos en el mundo de la programación. Si conoces alguna analogía que no esté aquí recogida, estaré encantado de añadirla 🙂

Las Parábolas del Software

Lo que pasa es que el tema de las metáforas sobre el desarrollo de software tienen un riesgo inherente, ya lo decía Martin Fowler en el 2004. Utilizar esta clase de paralelismos puede no ser la mejor forma de responder a las inquietudes o problemas de la persona que está pagando por tu trabajo. Sobre todo si tu argumento se apoya en un concepto que la otra persona puede contra-argumentar, lo que en la práctica supone que has trasladado un problema a un dominio semántico diferente, en el que quizá no seas experto o no te sientas tan cómodo.

• «9 mujeres no hacen un niño en 1 mes». Porque llega un momento en que por mucho que se añada gente a un equipo, la capacidad de reducir los plazos paralelizando el trabajo no es infinita. Sin embargo, tener un hijo es una tarea que por definición sólo puede hacer una persona y tiende a tardar en torno a 40-42 semanas. Por desgracia, lo normal es que tu proyecto de software incluya tareas que se pueden paralelizar hasta cierto límite y bajo ciertas consideraciones; y eso es exactamente lo que espera la persona que te paga por hacerlo: que seas capaz de organizar el trabajo de tu equipo dentro de ese límite.
• «Desarrollar software es como construir una casa: necesita unos cimientos sólidos para no derrumbarse». Por eso, antes de poner las cortinas en las ventanas hay que levantar las paredes. Muy bonito, si no fuera porque el proceso de hacer los cimientos de una casa está sujeto leyes físicas, como cálculos de cargas o resistencia de materiales, profundidad, disposiciones, drenajes… Y sobre todo, donde hay normativas que cumplir. Nada de esto aplica a tu proyecto de software, la solidez de los cimientos de tu arquitectura en general depende de la persona que la diseña, y de su experiencia. Aunque hay patrones más o menos estándar, cada empresa de software construye los cimientos de sus proyectos a su manera, y la persona que los paga tiene que tener la certeza de que se están haciendo de manera correcta.
• «Si quieres mover el baño 5cm, hay que tirar las paredes y romper los azulejos». Es una metáfora especialmente útil en aquellas situaciones en que si se hubieran pensando las cosas desde el principio, no habría que deshacer el trabajo. Nos lo recuerda habitualmente José Luis Vallejo, que además de ser mi CEO, es una de las pocas personas que conozco que ha lanzado una startup y se la ha vendido a Amazon. Sin embargo, a veces un cliente no quiere mover el baño, sólo quiere cambiar el modelo del sanitario, y para eso no hace falta picar el suelo ni romper los azulejos. Si lo haces, entonces tienes un problema.
• «No puedes tener un Ferrari GTO al precio de un SEAT Panda». Usado para expresar que hay una relación entre calidad, potencia, rendimiento, diseño… y el precio que se ha de pagar por ello. Esta metáfora parte de la base de que una persona no sabe distinguir lo que es un Ferrari GTO de lo que es un SEAT Panda; cuando muchas veces lo único que quieren es un SEAT Panda con un motor preparado, faros tipo rally en la parrilla y unas llantas molonas.

Ojito con el Panda de Carlos Sainz (Imagen de brb83 en Slot Adictos)

• «Esto tiene que hacerlo un experto, igual que no vas al dentista para que te opere de la cadera». No todas las personas son capaces de solucionar los mismos problemas, y con las mismas garantías. Lo que pasa es que tanto dentistas como cirujanos tienen una formación, una titulación y un Colegio que les habilita para hacer su profesión, de manera que cualquier persona puede comprobar su capacitación para esa intervención. Esto obviamente no ocurre en el mundo del software, donde muchas veces la única prueba que tiene el cliente de la capacitación del profesional proviene de su confianza en la empresa para la que trabaja.
• «Para hacer unos huevos con bacon, la gallina se involucra, pero el cerdo se compromete» Usado durante muchos años para diferenciar el rol de las personas que son responsables del resultado del proyecto (Product Owner, Scrum Master y Equipo de Desarrollo) y los que están informados, opinan, o lo pagan. Por cierto, hace casi 5 años esta analogía desapareció de la guía Scrum, pero hay gente a la que le gusta mantenerla.
• «No me pagas por apretar un tornillo, sino por saber qué tornillo hay que apretar». Es decir, no se juzga la tarea por la complejidad relativa a ojos de quién la observa, sino por el conocimiento que tuvo que adquirir el que la realiza. Esta es muy buena, y difícil de rebatir. En todo caso, diría que el problema muchas veces está en cuánto tiempo tarda un experto en encontrar el tornillo que hay que apretar, o que lo haga a través de un proceso de prueba y error que mine su credibilidad.
• «Un proyecto de software es como subir al Everest: sabes de dónde sales, dónde quieres llegar y el camino que vas a seguir, crees que llevas todas las provisiones que necesitas y todos los días rezas por que no empeore el tiempo» Una metáfora útil para explicar que por muy experto que uno sea, hay circunstancias que escapan a nuestro control y que pueden hacer que todo acabe en tragedia. Esta también es buena. Sin embargo, puede volverse en tu contra si tú asumiste la responsabilidad planificar la expedición para llevar al equipo a la cumbre y ahora estás perdido en medio de la ventisca y se te ha olvidado coger el teléfono con enlace satélite.
• «Programar es como conducir en mitad de un atasco, puedes ver lo que pasa a tu alrededor y tomar pequeñas decisiones, pero cambiar de carril no hará que el atasco termine antes» Útil para explicar que el ciclo de desarrollo es el que es, y llega un momento en que no puede acelerarse. Aquí lo que diría es que hay personas que no están dispuestas a comerse el atasco, y por eso sacan el Google Maps o el Waze antes de salir y coger una ruta más óptima, o que planifican su viaje para irse el día antes de la Operación Salida del Puente de Mayo.
• «Un proyecto de software es como jugar con un Lego: puedes hacer una casa o un coche encajando las piezas que hayas comprado» Esta analogía que me sugería Luis Sánchez incluye además que hay es necesario un diseño preliminar tanto de la construcción como de las piezas, y que puede que no todas las piezas que tengas las necesites, ni que hayas comprado todas las que necesitas. Lo que está claro es que si el cliente quería hacer el coche, tienes que haber cogido ruedas.
• «Cuando haces un jardín tienes una idea de cómo va a ser antes de plantarlo, aunque los detalles emergen después». Una idea de Félix Menéndez, que nos hace pensar que no sabes exactamente si debajo de la tierra habrá piedras, ni qué clase de insectos vas a encontrar, pero en cualquier caso, si no cuidas tu jardín seguramente las flores se sequen, y acabe todo lleno de malas hierbas. Interesante analogía, en este caso yo diría que es responsabilidad del jardinero haber elegido qué semillas tenía que plantar conociendo su ciclo de floración, cuándo había que regar, etc.
• «Un proyecto de software es como hacer un pastel: necesitas una receta, reunir los ingredientes adecuados, seguir las instrucciones y respetar los tiempos de horneado» Esta idea foodie me la sugiere Daniel González, muy apropiada porque en la oficina echamos de menos las tartas que traía (a él también le echamos de menos) En este caso, es responsabilidad del cocinero haber comprado el producto en el Club del Gourmet o en los chinos. También diría que en el caso del software a medida, es el cocinero el que se ha inventado la receta, y que seguir la receta de un tercero no siempre es suficiente.

Loca academia de cocineros

• «Construir software es como levantar una Catedral: una combinación de arte y ciencia». Los que hemos leído «Los Pilares de la Tierra» nos sobrecogemos pensando en proyectos de 30 años y los malvados Hamleigh cuando Victor Sánchez utiliza esta metáfora. Tiene una derivada, y es que a veces las personas que están picando las piedras se olvidan de que su propósito es construir una catedral. Lo malo de construir catedrales es que a veces te coge a medio camino el cambio del románico al gótico.
• «Desarrollar software a medida es como resolver un puzzle cuyas piezas tú mismo estás construyendo» Esta analogía es, hasta donde yo se, de mi propia cosecha. No recuerdo haberla leído, y estoy seguro de usarla desde el año 2008. Si estás resolviendo un puzzle y cambia la imagen de la referencia, seguramente las piezas que has construido ya no te sirvan. Como es mi propia analogía dejaré que seáis vosotros los que hagáis la contra-argumentación 🙂

¿Conoces más metáforas? Estoy ansioso por incorporarlas.