Desde que escribí mi primera línea de código, hace ya unos cuantos años, siempre he percibido un ruido de fondo en la industria del software. Un ruido continuo y pertinaz. Un ruido que como un murmullo que vive entre las líneas de código dice: 'el desarrollo de software es una actividad industrial'. Parece que hay mucha gente que está convencida de esto, que a mí me parece una falacia. Y que nadie piense que uso aquí la palabra falacia con un signifacado relajado, lo uso con todo su significado, según la RAE: 'Engaño, fraude o mentira con que se intenta dañar a alguien'. Numerosísimas empresas trantan de hacernos creer que los desarrolladores somos meros peones intercambiables, piezas remplazables de una cadena de montaje, minusvalorando nuestra labor y dañando nuestras legítimas aspiraciones de reconocimiento profesional y económico. Y creo que se trata simplemente de no querer repartir el pastel, pero esta es otra historia. Creo que es hora de asumir que esta es una ingeniería en la que el valor está en sus profesionales más que en ningún otro aspecto y sobre todo una ingeniería que debe comenzar a trazar su propio camino.
Hay una serie de razones por las que a mí me parece evidente que si bien la ingeniería del software es sin duda una ingeniería (necesita del ingenio más que ninguna otra) es radicalmente diferente de la ingeniería industrial o la arquitectura u otras ingenierías digamos clásicas.
Es por eso que cualquier metáfora en la que se usen símiles con otras ingenierías es dañina en mi opinión y en la opinión de muchísimos otros miembros de la comunidad más relevantes que yo. Existe una gran controversia sobre este tema y como nó, me gustaría añadir mi granito de arena o más leña al fuego según como se mire.
Mi amigo Ibon Landa hablaba sobre esto a raíz de un anuncio de una empresa en dotNetMania y mucha gente me ha preguntado mi opinión sobre el tema, supongo que como consecuencia del revuelo que se armo cuando comenté otro anuncio anterior de la misma empresa, pues aquí va este post, en el que trato de explicar porque considero la ingeniería del software diferente a otras ingenierías y el desarrollo de software algo difícilmente industrializable.
Aunque considero que existen muchos motivos por los que el desarrollo de software es diferente voy a comentar los que me parecen mas relevantes:
En el desarrollo de software no es económico hacer todo el diseño y la especificación a priori
Diseño de Gaudi Cuando se trata de construir miles de vehículos tiene un gran sentido hacer una fortísima inversión en diseño y especificación a priori. Esta fortísima inversión se recupera diluyéndola en el coste de la gran cantidad de instancias de ese diseño que se van a implementar. En software esto no es cierto. De un diseño solo se hará una implementación (por mucho que se vendan millones de cds con ella) solo tendremos una instancia de un diseño determinado.
Otra diferencia importante es que el software no se puede construir principalmente uniendo elementos que ya existen. Durante un tiempo se pensó que si, incluso es algo que se persigue constantemente primero con el software construido mediante componentes y luego mediante el software construido orquestando servicios. Aunque ambos enfoques han ayudado a mejorar como se construye el software ninguno de los dos no libra de que todo proyecto tenga más líneas de código nuestras que ajenas. En la construcción de un coche, un barco, un avión o un edificio, lo que se reutiliza es mucho más significativo que lo que se construye de cero. Esto hace que, a igual magnitud del proyecto, el software sea mucho más difícil de especificar que un coche, un edificio o un barco: no podemos ahorrarnos diseño simplemente diciendo aquí se usa una capa de acceso a datos DIN 5722, sin embargo este enfoque es constante en la industria y la construcción.
Durante años se nos ha vendido que era posible la reutilización a gran escala, incluso se nos ha vendido herramientas 4GL que hacían de la especificación y el diseño a priori el enfoque primordial de desarrollo, pero sin duda los compiladores generalistas siguen siendo la principal herramienta de desarrollo. Si bien es cierto que cada vez se hace más uso de herramientas estilo DSL, estás no ha solucionado el problema de manera completa.
Con independencia del diseño que se haga a priori, cada línea de código que se escribe exige actividades de diseño. Sin embargo en otras ingenierías las actividades de construcción no implican tomar ninguna decisión sobre el diseño. El simple hecho de elegir el tipo de una variable numérica es una decisión de diseño. Solo los artistas toman tantas decisiones de diseño como los programadores cuando construyen algo, quizás por eso somos muchos los que pensamos que programar es un arte.
El entorno cambia constantemente
Cuando alguien se plantea construir un puente o un barco conoce de antemano el problema que va a solucionar. Este problema permanece constante en el tiempo. Esto no ocurre con el software. Los clientes a menudo necesitan saber que somos capaces de hacer antes de conocer realmente que es lo que quieren hacer. Nadie opina sobre el diseño de un puente porque reconstruir uno de sus tramos es sumamente costoso y rara vez hay valor alguno en esa reconstrucción. Sin embargo cuando un cliente, o un usuario ve un software, siempre se le ocurren maneras de cambiarlo para lograr obtener más valor. Evidentemente esto exige nuevas maneras de relacionarse con los clientes.
Además las herramientas , los lenguajes, las necesidades de calidad, los requisitos de rendimiento cambian, como mínimo, de proyecto a proyecto. En este entorno es poco interesante centrar tus esfuerzos en realizar un proceso repetible, es mucho más interesante buscar un proceso flexible. Esto no se da de manera tan clara en la industria o en el resto de ingenierías, el proceso básico de construcción de puentes y sus diseños no han cambiado desde la época de los romanos. Todos los puentes, por poner un ejemplo, tienen requisitos esenciales muy similares: unir dos puntos salvando un obstáculo. ¿Alguien podría hacer una descripción similar de los proyectos de software?.
Otra manifestación de esté cambio constante, de la relatividad de los datos que majamos, que nos aleja de otras ingenierías es la imposibilidad de utilizar métricas prescriptivas. Que el momento flector de una viga en voladizo supere cierto valor, sin duda dará como resultado que se rompa, pero, por poner un ejemplo, ¿cuál es el valor máximo de bugs abiertos que puede tener un proyecto antes de que la calidad percibida sea mala?. Es muy difícil gestionar los proyectos de software de manera puramente analítica pues la certidumbre es poca y la posibilidad de sesgar las métricas es amplia.
No existen actividades repetibles
Barco en construcción Cada línea de código, unidad cuántica de los proyectos de software, es única y solo es relevante en un contexto determinado. La industrialización se basa en la especialización y la repetibilidad. Todos los tornillos de rosca métrica son idénticos. Sin embargo no hay valor en construir dos piezas de software que sean idénticas.
Durante el desarrollo de un proyecto industrial o de construcción existen numerosísimas actividades que se repiten de manera idéntica. Incluso vasta con repetir elementos constructivos ensamblándolos para logra más funcionalidad. Basta añadir secciones para lograr un barco con más capacidad o basta con añadir más módulos para lograr una Terminal 4 de Barajas. Esto no ocurre en el software, cada módulo es radicalmente diferente del anterior al menos en algún aspecto. Por eso la especialización de los 'operarios informáticos' es, en cierto modo, contraproducente.
Además los desarrolladores se ven a si mismos más como artesanos que como operarios cuando describen su actividad profesional, por algo será.
La fuerza productiva no es fácilmente reemplazable
Y el desarrollo de software exige personal altamente capacitado. No existen dos desarrolladores con las mismas capacidades. Es relativamente fácil entrenar a un nuevo operario de planta es relativamente fácil sustituirlo por otro y la productividad no se verá mermada. Se puede tratar a los operarios de una planta como una máquina más (no digo que esto sea correcto, digo que es posible). Evidentemente las máquinas son fácilmente reemplazables al menos sobre el papel.
Todos los que hemos gestionado proyectos coincidimos que sea cual sea el proceso de desarrollo que seguimos el que un desarrollador cause baja siempre es un problema. Sabemos que nunca encontraremos otro con los mismos conocimiento y destrezas y con el conocimiento sobre el proyecto que el anterior atesoraba. Este es un tema que ya he tratado en anteriores ocasiones y por tanto no me extiendo más.
El software puede proporcionar valor incluso cuando no está completado
Puente en construcción Medio coche, medio barco, medio edificio o medio puente no sirven de nada. No son utilizables, no suponen un retorno de la inversión y además no se puede recibir feedback ninguno sobre el retorno de la inversión recibido frente al esperado y como mejorar este ratio.
La mitad de un proyecto de software, considerada como el momento en que la mitad de los requisitos están implementados, si se ha considerado el retorno de la inversión como principal parámetro a la hora de priorizarlos, aportará típicamente más de la mitad del retorno de la inversión esperado. Además es posible poner en producción la mitad de un software. No estará completo, cierto, pero no ayudará en múltiples aspectos. Dicho de otra manera Open Office es rival de Microsoft Office por un motivo claro, no necesitamos absolutamente toda la funcionalidad para que un software aporte valor. Además esta característica del software hace que sea mucho más fácil obtener feedback e incorporarlo al proyecto.
Existe un consenso claro entorno que a que una aproximación iterativa es la mejor manera de desarrollar proyectos de software. Sin embargo la aproximación en los proyectos industriales o de construcción rara vez es iterativa más haya de la fase de prototipado.
La motivación de los desarrolladores es lo que más influye en la productividad
Aunque existen muchos estudios y experiencias que hablan de que la implicación de los operarios de cadenas de montaje en el proceso productivo de principio a fin a logrado grandes mejoras de productividad, es cierto que el impacto de la motivación de los operarios industriales sobre el resultado final y la productividad es limitado.
Sin embargo, numerosísimos autores sobre gestión de proyectos informáticos han resaltado la motivación y la capacidad de trabajar como un equipo con el factor más determinante sobre los resultados de un proyecto. El primer autor en hablar y describir este fenómeno fue Boehm en 1981 y desde entonces son incontables los gestores de proyectos y las metodologías que lo han ignorado.
Dicho lo anterior, creo que es hora de olvidarse de tratar de llevar las técnicas de otras ingenierías y empezar a asumir que la nuestra es diferente y que debe encontrar su propio camino. Ya hay grandes nombres que está andando ese camino.
