No es un tema novedoso, más bien al contrario. Pero es un tema entretenido que últimamente me he cruzado en varias conversaciones en twitter y me parece una ocasión como otra cualquiera para escribir sobre él: ¿los desarrolladores de sofware somos ingenieros o artesanos?

Vaya por delante que no pretendo repartir ni títulos de ingeniero ni pegatinas de crafter-clean-coder. De hecho, si algo comparten ambas visiones es cierto elitismo que no me gusta. También quiero dejar claro (aunque ya lo hice en su día) que no considero necesario ningún título para ejercer esta actividad, así que cuando hablo de ingeniería no me refiero tanto a unos estudios reglados sino en una forma de hacer las cosas.

Soy ingeniero

ingeniería: conjunto de conocimientos orientados a la invención y utilización de técnicas para el aprovechamiento de los recursos naturales o para la actividad industrial.

Esa es la primera acepción de ingeniería que aparece en el DRAE (énfasis mío). Cuando terminé la carrera de Ingeniería Superior Informática en el año 2001 y me convertí en ingeniero (bueno, más bien me dieron un título que ponía eso), mi visión del desarrollo de software cuadraba bastante bien con esa definición.

Entendía que el desarrollo de software era una actividad industrial y, como tal, podían aplicarse diferentes técnicas para gestionarla, controlarla y dirigirla. Mis conocimientos eran bastante escasos, pero asignaturas como Ingeniería del Software me habían enseñado (es un decir) que existían metodologías que podían ser aplicadas al proceso de desarrollo que permitirían convertirlo en algo parecido a una cadena de montaje.

Se podía partir todo el proceso en distintas fases, perfectamente delimitadas, en cada de una de las cuales entrarían en juego los roles apropiados para producir el resultado esperado. Así, tendríamos una fase de análisis de requisitos en la que analistas funcionales generarían un documento de especificación de requisitos, una fase de diseño en la que arquitectos y diseñadores mapearían esos requisitos a componentes, una fase de implementación en las que se programarían los requisitos o una fase de pruebas en las que se verificaría que la implementación era correcta.

Al tener todas estas fases, roles y entregables tan bien definidos, era fácil establecer la analogía con cadenas de montaje (esa actividad industrial a la que hace referencia la definición de la DRAE) y subestimar el componente humano de cada una. A fin de cuentas, picar código es picar código y cambiar un programador por otro no debería ser problema, o incluso subiendo el nivel de abstracción, el mismo razonamiento podía ser aplicado a analistas, arquitectos o diseñadores.

Cuando empecé a trabajar en el Mundo Real™, con proyectos reales, mis convicciones emperazon a tambalearse. Por mucho que intentara aplicar lo que (creía que) sabía sobre Ingeniería del Software, la realidad se empeñaba en no hacerlo funcionar. Las fases no se podían marcar tanto, los requisitos nunca llegaban a estar completamente definidos, había que saltar hacia delante y hacia atrás entre fases continuamente y, por supuesto, las personas eran clave. Si alguien conocía una parte del código o del negocio, no era fácilmente reemplazable. No había ningún tipo de magia que permitiera coger la documentación de un proyecto (generalmente incompleta y desactualizada) y hacer que alguien siguiera con él como si nada hubiera pasado.

Parecía que todo aquello que había aprendido no fuera aplicable al mundo real, o al menos a mi mundo real, y que en equipos pequeños todo esto de los procedimientos establecidos, las metodologías, los entregables y demás, no eran más que una pérdida de tiempo que no servía para gran cosa ante clientes con requisitos cambiantes y plazos agobiantes que impedían ponerse a generar y mantener documentación.

Me he sentido artesano

En ese escenario es comprensible que, cuando conocí una cosa llamada manifiesto ágil me resultara atractiva. De repente había encontrado gente que asumía mi realidad de cada día y, en lugar de intentar luchar contra ella, intentaba trabajar lo mejor posible con (o a pesar de) ella.

Ideas como valorar más los individuos que los procesos, el software que la documentación, la colaboración con el cliente que discutir eternamente documentos de requisitos, o la capacidad de adaptación frente a seguir un plan preestablecido resultaban prometedoras.

Por aquella época surgió el movimiento de ALT.NET que me ayudó a conocer otras formas de trabajar. Hay que tener en cuenta que hasta ese momento mis referencias sobre cómo había que hacer las cosas eran guías de empresas como Microsoft o Sun, siempre enfocadas al desarrollo enterprise (en el peor de los sentidos) y al demoware. Aprender sobre DI, TDD, integración continua, programación extrema o refactorización me llevó a un mundo en el que me sentía más cómodo. Esas sí eran herramientas que podía utilizar en mi día a día y a las que sí que les sacaba partido, no a esas teorías antediluvianas de desarrollo en cascada que había aprendido en la universidad.

De ahí a empezar a sentirme más cercano al movimiento de software craftsmanship había un paso. Sí, seguía siendo un ingeniero (tenía mi título), pero cada vez me veía más como un artesano:

artesano: persona que ejercita un arte u oficio meramente mecánico. Usado modernamente para referirse a quien hace por su cuenta objetos de uso doméstico imprimiéndoles un sello personal, a diferencia del obrero fabril.

La segunda acepción de la DRAE (enfásis mío) cuadra muy bien con lo que pensaba. Desarrollar software no era como trabajar en una cadena de montaje. No éramos obreros reemplazables en una fábrica (siempre me espantó -y lo sigue haciendo- el concepto de software factory), sino que imprimíamos nuestro sello personal.

Aunque siempre he valorado mucho la formación teórica que recibí en la carrera, esto me hizo también cuestionarme cuánto de lo que había aprendido en lo referente a desarrollo de software me servía para algo y si no sería mejor seguir esa línea de formación de la que hablaban algunos con sus aprendices y maestros, transmitiendo y compartiendo conocimento mientras trabajan juntos programando por parejas.

Todo esto estaba muy bien, pero al cabo del tiempo empecé a ver cosas que me encajaban menos.

Casi todo acaba justificándose porque «el desarrollo de software es una actividad muy compleja, que no se puede comparar a otras áreas como al ingeniería civil». Eso hacía que, si por ejemplo, estimar era difícil, la solución propuesta fuera no estimar, o que se infravalorase el conocimiento formal a la hora de optimizar el rendimiento, o que se llegara a ignorar las características de herramientas complejas y potentes pensando que con un poco de pair programming y unos tests se podían obtener resultados equivalentes.

Y ahora…

Ahora no sabría muy bien como clasificarme, pero creo que vuelvo a acercarme más a la idea de desarrollo como ingeniería que como artesanía.

Ya no creo, como me pasaba hace 20 años, que sea posible desarrollar software como el que construye casas (cuánto daño ha hecho ese símil), y seguramente la industrialización del desarrollo de software no pase por establecer procesos mecánicos que permitan convertir a las personas en recursos intercambiables supeditados a esos procesos. Creo que hay un componente de libertad en el desarrollo que requiere cierto arte, talento, o como prefieras llamarlo, que está más allá de reglas preestablecidas. O al menos, que no es fácil enmarcar dentro de unas cuantas reglas que podamos seguir al pie de la letra.

Hay una parte del desarrollo que tal vez no sea ingeniería y esté más relacionada con comunicación, exploración de soluciones y habilidades menos formales. No sé que porcentaje del desarrollo es esa, pero hay otra parte que sí es ingeniería y deberíamos ser «más ingenieros». Puede que no seamos capaces de convertir el desarrollo de software en fabricación de sillas, pero hay aspectos concretos que podemos tratar con un rigor similar al que usaría un arquitecto para elegir sus materiales.

Tenemos a nuestra disposición teoremas sobre sistemas distribuidos, formas de tratar con fallos, leyes sobre optimización, análisis de complejidad de algoritmos y un sinfín de herramientas rigurosas que podemos utilizar.

Como escribía hace poco Gonzalo, debemos huir de ese relativismo al que nos agarramos con tanta frecuencia. Sí, el contexto importa, pero eso no hace que todo valga. Fijado un contexto, podemos encontrar técnicas objetivamente mejores, y eso es lo que debemos hacer: fijar contextos y trabajar sobre ellos. No se trata de buscar balas de plata, sino de saber qué tipos de balas son útiles en cada caso, y no, no todas las balas sirven para todo.

La cuestión real

La cuestión de fondo, y eso es mucho más entretenido que mis vaivenes a lo largo de los años, es hasta dónde se puede llegar a formalizar el desarrollo de software como disciplina.

La visión clásica que trataba de equiparar el desarrollo de software a otras ingenierías asumía que se podía formalizar mucho. Igual que con el tiempo se habían creado mecanismos estandarizados para construir distintos tipos de puentes, o edificios, o barcos, se podían crear mecanismos estandarizados, fiables, replicables y predecibles para desarrollar software.

La perspectiva más agile/craftsman/moderna (y sé que estoy mezclando cosas, pero creo que se entiende a dónde quiero llegar), parte de la idea de que no se puede formalizar tanto, y hace falta tener más flexibilidad. O al menos, que conceptos básicos de otras ingenierías (como estimación de tiempos y costes) no son trasladables al desarrollo de software por la propia naturaleza de la actividad.

Normalmente se suele argumentar que el desarrollo de software tiene muchos más grados de libertad que otras disciplinas en las que las restricciones impuestas por el mundo físico (los materiales para construir un puente son los que son, es fácil determinar la longitud o anchura necesaria, etc.) hacen que sea mucho más sencillo cerrar unos requisitos claros al principio de un proyecto y elegir la forma de llevarlo a cabo.

No tengo ni idea de si eso es así o no en la vida real, pero supongo que habrá casos en los que un arquitecto no tenga que pensar mucho para construir una casa y pueda replicar el mismo proyecto que hizo para la casa anterior, y habrá otros en los que le pidan el nuevo edificio de oficinas de MegaCorp y la parte de definición de requisitos y alcance del proyecto sea bastante más complicada.

En cualquier caso, al final se trata de ver si es una cuestión ontológica o epistemológica. Si realmente la naturaleza del desarrollo de software es tal que no es posible abordarlo mediante técnicas de ingeniería «clásica» y está más cerca del «arte» o de la «artesanía», o si, en el fondo, estamos limitados por nuestro conocimiento actual.

No hay que olvidar que cuando comparamos el desarrollo de software con disciplinas como la arquitectura estamos comparando algo 100 años de historia con unos cuantos milenios. En los casi 5.000 años que han pasado desde las pirámides de Egipto hasta ahora, la arquitectura ha tenido tiempo de evolucionar. ¿Os imagináis cómo será el desarrollo, no dentro de 5.000 años, sino dentro de 500? ¿Realmente podemos estar tan seguros de que todas esas incertidumbres que vemos ahora no serán fácilmente decidibles entonces?

La verdad es que no tengo ni idea de lo que pasará, pero lo que «la naturaleza del desarrollo lo hace imposible de gestionar como otras ingenierías», me parece que sólo podría tener sentido dentro del contexto de conocimiento actual y no es tanto «la naturaleza del desarrollo», sino «con lo que nosotros sabemos hoy del desarrollo».