Metáforas sobre el desarrollo de software

En mi quehacer diario, me encuentro con dificultades para comunicar o hacer ver las dificultades inherentes a todo desarrollo de aplicaciones informáticas, sin importar su tamaño, complejidad o alcance.

Así hoy quiero realizar un ejercicio de pensamiento en voz alta y utilizar metáforas para describir el trabajo que hacemos y las cosas que no podemos, aun siendo consciente que significa una simplificación grosera de la realidad.

El trabajo de desarrollo de aplicaciones informáticas (eso, llamado programación) es algo especialmente complejo.

Requiere una tenaz dedicación, curiosidad, capacidad de estudio, comprensión, disciplina, concentración y creatividad, para conseguir que una máquina electrónica haga justo lo que queremos que haga cuando ella solo entiende unos, ceros y decisiones lógicas primitivas.

Por encima de esta capa física, se acumulan capas y capas de abstracciones y herramientas, que aumentan en cada una de ellas la complejidad de la anterior, sumando cada vez los conocimientos necesarios para hacer hasta el más sencillo programa.

Y, además, se trabaja casi siempre en equipo. Ya que las aplicaciones generalmente abarcan mucho más de lo que un profesional en solitario puede realizar con comodidad y calidad.

Metáfora de la Orquesta

Así lo que más cercano me parece, es asemejarlo a una orquesta sinfónica en donde cada intérprete debe dominar a fondo su instrumento musical; todos los participantes orientan sus esfuerzos, capacidades y talento en conseguir una obra en conjunto; y hay una visión general e inspiradora del objetivo final.

Pero en esta "orquesta" de programadores hay que señalar que no hay ensayos, como mucho uno solo y de uno pocos minutos. También casi siempre la orquesta no sabe que pieza se va a tocar - la obra a interpretar se esboza al principio del concierto y se va componiendo durante el mismo - por lo cual tampoco se sabe que instrumentos y músicos se van a necesitar.

En este concierto, la duración debe ser estricta al segundo, sin posibilidad de cambios en los tempos musicales; siendo el formato del concierto aquel el que los intérpretes compongan la nueva partitura durante una hora, que el público escuche la interpretación durante un minuto de reloj, y que con eso valoren si les gusta y si quieren modificaciones sobre lo compuesto.

Una vez acabado el concierto, los asistentes se ponen unos auriculares, y mientras escuchan la grabación de la composición interpretada por la orquesta, piden cambios de tono, de armonías, de melodías, de instrumentos y ritmo.

La falsa metáfora de la Arquitectura

Mucha gente continúa utilizando la falsa metáfora de los arquitectos para definir el trabajo de un equipo de desarrollo. Suponiendo esto una rígida estructura piramidal compuesta por Jefe de Proyecto, Arquitecto de software, Analista funcional, Analista programador, tester, diseñador, etc.

Pero realmente esta metáfora no es cierta ni se puede aplicar desde el momento en que si el desarrollo de software fuera similar al construir un edificio, este se se empezaría por cualquier punto del plano: una ventana en el aire, el tejado o el color de las paredes aún inexistentes.

Dicho plano cambiaría cada reunión de seguimiento o en cada visita del contratista o cada vez que soplara un viento fuerte en la estepa de Manchuria y, cuando se llevarán construido 7 pisos de los 13 y medio de que constará el edificio (en ese momento de la revisión), se pediría añadir otro piso entre la planta 2 y la 5.

Cambiar de posición el hueco del ascensor, es otro clásico del desarrollo de software. Como que el piso 7 - que aún no está construido, ni entra en el proyecto - sea 3 veces más ancho que alto en relación a la planta baja.

Y ya que estamos, el promotor insiste en que hagamos un garaje para helicópteros en el sótano, pero que la entrada de los aerodinos quede camuflada de forma que no rompa el estilo rococó de la fachada del edificio.

Por último, si al desarrollo de software le aplicamos las técnicas arquitectónicas, los cimientos se harían con Kriptonita, la mitad de la izquierda superior con ladrillo cocido, tres cuartas partes en cartón piedra, y el último piso (ese, que está debajo de las primeras 23 plantas) en hierro forjado con chapas de media pulgada.

Buscando culpables... lo somos todos

Creo que el origen de muchas confusiones viene por el desconocimiento general de lo que es el desarrollo, y la percepción de la sociedad de que somos unos frikis que hacemos las cosas por amor al arte, que el software es gratis - por supuesto - y que cualquiera puede programar (pero no hacer funcionar un fax).

En el ámbito profesional la cosa se pone de "color hormiga", es decir muy cuesta arriba, cuando los que deciden están convencidos que un desarrollador puede programar en cualquier lenguaje, como si fuéramos conductores y por ello pudiéramos conducir cualquier vehículo.

Pero a nadie se le ocurre que alguien poseedor de un permiso del tipo B (automóviles de 3.500kg. y hasta 9 plazas) conduzca camiones de mercancías peligrosas, una máquina excavadora, un tanque o un Formula 1. Al igual que a nadie llevaría un traductor de japonés a una negociación en chino mandarín, por muy rasgados que todos tengan los ojos por esos lares.

Así llegamos a que el desconocimiento aboca al gestor y al cliente a intentar controlar la situación por medio de estimaciones, y así saber el "tamaño" del esfuerzo y el coste del proyecto.

La metáfora del médico

Pedirle estimaciones a un equipo de desarrollo se puede asemejar a pedírselo a un médico.

Nadie se creería que un facultativo te dijera que estarás sano el martes de dentro 13 días, y que el 14 de enero a las 18:00 se compromete a hacer que tu pierna recién cortada, haya crecido de nuevo - pernera del pantalón incluido. Al igual que en desarrollo, hay demasiadas variables en juego.

La primera es la propia dificultad del diagnóstico; seguido por los múltiples frentes de ataque que abre una enfermedad de forma simultanea; las enfermedades que se aprovechan de la principal (como los "ya que estamos" de los requisitos); y los múltiples y siempre cambiantes procedimientos, tratamientos y curas.

Sería igual de absurdo exigirle a un médico que se "comprometa" a tener el 70% de la enfermedad curada dentro de 34 jornadas, partiendo de la base de que el concepto de porcentaje es binario (o llegas o no) y que la definición de "curado" es siempre relativa.

¿Entonces cuál es la solución más obvia si hay un compromiso de fecha? Añadir más "recursos" al proyecto.

Pero esto es como pensar que si una mujer tiene un niño en 9 meses, si añado una madre más a la ecuación el parto se adelantará unos meses; o que si en una operación de corazón abierto asigno cinco cirujanos en vez de dos, se completara la intervención en tres veces menos tiempo.

Y cuando el proyecto está definitivamente fuera de cualquier estimación y aparecen las "desviaciones", sale a la palestra la solución definitiva: echar horas.

Lo cual es igual que decirle a un corredor de maratón, que para poder llegar en el tiempo estimado y "comprometido" lo que tiene que hacer es correr al doble de velocidad en los últimos 5 kilómetros, como si eso no fuera absolutamente negativo en una actividad en donde el límite de concentración productiva apenas supera las seis horas (en el desarrollo de software) y a partir de las 12 horas eres un zombie que tardará días en recuperar el ritmo, la capacidad de trabajo y el porcentaje de fallo.

Sin duda podría continuar con alegorías y semejanzas durante más párrafos. Todas y cada una de ellas es un intento de simplificar y mostrar las dificultades, situando en otro contexto las características inherentes al desarrollo de software.

Pero creo que es un buen momento para detenerme y pedirte a ti, lector de GenbetaDev, medites sobre estás metáforas y opines sobre ellas, o añadas las tuyas propias.