De ingeniería y programación

Leo un artículo, que me recuerda un antiguo mito, que sigue siendo una poderosa lacra en nuestra vida de desarrolladores de software...¿o debería decir ingenieros de software?

El problema es que se quiere evitar el uso de técnicas de ingeniería, el uso de la aproximación científica y el acopio metodológico tradicionalmente asociados al término ingeniería. Sin embargo, no son pocos los que se apuntan al carro de usar la coletilla "ingeniero" en su título o en su actividad, y defienden lo que una ingeniería debe ser (o al menos lo que ellos quieren que sea, acorde con sus expectativas).

Vemos habitualmente en blogs y artículos, la defensa de frases como "construir software no es como fabricar coches o casas". Normalmente los argumentos ofrecidos intentan separar el mundo de la ingeniería tradicional, con el de la construcción del software (aquí he evitado explícitamente el uso del término ingeniería del software). Lo peor de todo, lo que resulta más flagrante, es que se pretende apoyar el uso y efectividad de las metodologías ágiles como resultado de todo esto. Las técnicas ágiles están ahí, y son tan buenas como adecuadas en la situación concreta en que de buenos resultados. Pero eso no convierte en ciertos los argumentos.

Veamos algunos argumentos:

•  Los coches se fabrican en serie. Son todos iguales. El software es siempre distinto. Falso: realmente, al construir coches, es exactamente igual que en el software. Tenemos máquinas, robots y técnicas de ingeniería para tratar de que todos los coches salgan parecidos, pero es inevitable que todos salgan realmente distintos. Donde entra la ingeniería, es en tratar de que todos sean razonablemente parecidos, dentro de unos márgenes.
• La ingeniería es para fabricar "en serie", "como churros", al contrario que el software, que es siempre distinto. Falso: la mayoría de creaciones en el mundo de la ingeniería son únicas: puentes, pasos elevados, máquinas, mecanismos, etc. La visión de la ingeniería enfocada a la producción en serie es una manipulación enfocada única y exclusivamente a crear la ilusión de que la ingeniería y el software son radicalmente distintos.
• Las ingenierías clásicas precisan mucho de un diseño previo a la construcción, el disponer de los planos del arquitecto siempre antes de empezar el edificio. Falso: ¿es innecesario el tener las especificaciones de lo que hay que construir? Por supuesto que podemos construir casas sin planos, sin cimientos, etc. Eso no significa que la experiencia recomiende lo contrario.
• Los planos para construir son precisos. Falso. Existe una cosa en ingeniería llamada tolerancias. Significa simplemente que como las cosas se construyen de forma más o menos artesana, existen unos límites razonables entre lo que el ingeniero o proyectista desea, y los resultados reales obtenidos por la persona que realiza la tarea. Esto significa que el ingeniero desea un resultado, pero es consciente que al llevarlo a la práctica habrá desviaciones. Los planos pretenden que estas desviaciones, estén "contenidas". Además, los planos no son siempre tan precisos, puesto que muchas veces se deja en manos de quien fabrica, algunas tomas de decisiones, siempre que no se altere el resultado deseado.
• En el software, al contrario de la ingeniería, es casi imposible que no cambie el diseño. Falso al compararlo con la ingeniería. En ésta, incluso al fabricar coches (que nos parecen todos iguales aunque esto no sea así), las especificaciones cambian durante la creación de las máquinas que van a servir para construir los coches, durante la instalación de esas máquinas, pero es que también durante la vida del modelo de coche. Esto se ve incluso en las casas: los planos cambian durante la construcción (e incluso después).
• El sueño de construir software como en una cadena de montaje no es realista. Inexacto: no tiene nada que ver la fabricación en serie con el tema a tratar. Una cadena de montaje es un resultado de aplicar prácticas de ingeniería, pero no es la ingeniería. Realmente una cadena de montaje sería un software de creación de software (como puede ser Genexus). Alguien ha construído la cadena de montaje, que esa sí es el fruto del trabajo de ingeniería. Existen aplicaciones que son "fábricas de software", y que sí que tienen siempre el mismo resultado para los mismos datos y situaciones de entrada (de hecho mucho más que los coches en el caso de la fábrica, que como hemos visto, no son nunca iguales).

¿Qué ocurre entonces? ¿Estamos diciendo pues que son exactamente iguales la construcción del software y la ingeniería tradicional? Pues va a ser que no. Lo que significa es que la construcción del software no debe prescindir de una herramienta fundamental como son las técnicas de ingeniería, la planificación, etc. Por supuesto que podemos hacerlo. Como es posible hacer cualquier cosa. Pero vivimos en un mundo en el que no es despreciable el obtener resultados predecibles y controlados (dentro de unos márgenes, claro. Todo tiene su tolerancia). Las empresas necesitan prever los gastos que van a tener, porque normalmente (y digo normalmente), los empleados no estamos construyendo software sólo por amor al arte, sino que exigimos una remuneración a cambio. Y una remuneración fija. A ver si ahora vamos a inventar el cobro del sueldo "iterativo", basado en las funcionalidades que hemos completado.

El día en que la premisa fundamental sea tener un producto en el mercado a toda costa...habremos perdido una parte esencial de nuestra profesión.