Dos razones por las que desarrollar software no es lo mismo que fabricar coches o construir casas (1/2)

(Enlace a la parte 2 de este artículo: Dos razones por las que desarrollar software no es lo mismo que fabricar coches o construir casas (2/2))

Construir software no es igual que construir un puente, un edificio o un coche. Y difícilmente llegará a serlo. Porque el producto final, el software, tiene diferencias muy sustanciales con estos productos físicos. Estas diferencias hacen que el proceso de construcción sea diferente.

Y obviar estas diferencias puede implicar importantes problemas a la hora de desarrollar, planificar, gestionar, etc., un proyecto software.

Diferenciar el cómo se construye el software de cómo se construyen los productos físicos es además uno de los pilares de las metodologías ágiles. Y un tema del que se ha escrito mucho; uno de los textos que personalmente más me gustaron cuando lo leí hace tiempo es “la nueva metodología” de Fowler, del que se extraen muchas ideas de este post. Y también se ha debatido bastante (de hecho, la idea de este post viene de un comentario de @joserra_biko), con posturas a favor y en contra.

Y aunque seguro que habrá muchas más razones, os dejo dos, las dos que en mi opinión son más significativas del porqué fabricar software no es lo mismo que fabricar coches o construir casas: La diferente separación entre diseño y construcción y la diferente distribución de los costes del proyecto.

1 – La diferente separación entre diseño y construcción

En ingeniería software, a diferencia de en la arquitectura u otras ingenierías tradicionales, no se puede separar tan claramente la fase de diseño y de la de construcción. 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. Los planos para construir son precisos. Y los realizan personas ajenas a la fase de construcción (los arquitectos). La construcción tiene poco componente intelectual y mucho manual. Y todo esto hace que existan dos actividades claramente diferenciadas: el diseño y la construcción.

Desde sus orígenes, la ingeniería del software intentó perseverantemente emular a las ingenierías clásicas. Tener una fase de diseño muy separada de la codificación. Que la codificación no comenzase hasta que terminase el diseño. Que el diseño concluya con unos planos precisos que guíen totalmente la construcción. Que una vez que se hace un diseño este no se modifique. De hecho, notaciones para “planos” como UML y ciclos de vida como el cascada puro (donde cada fase se hace una sola vez y no se pasa a la siguiente fase hasta que se termina la previa) nacieron con este objetivo.

Pero en software está demostrado que es muy difícil especificar en la una única y primera fase  de diseño todas las cuestiones a tratar en la programación.

Por la complejidad de muchas de las reglas de negocio que automatizamos cuando construimos software es muy difícil saber qué software se quiere hasta que se trabaja en su implementación. De ahí que en software diseño y construcción se solapen, y que por ello que muchas veces se recomiende construir por iteraciones y el uso de prototipos incrementales.

A la mayoría de los diseños de las ingenierías clásicas, arquitecturas, etc., no les sucede esto porque pueden hacer un mayor uso de las matemáticas, en software no es así. Y aunque se pretenda emular ese modo de fabricación, en software no funciona bien, y debemos tener muy claro que es casi imposible cerrar un diseño a la primera para pasarlo a codificación sin tener que modificarlo. Así que, salvo que se descubra algo nuevo, el sueño de construir software igual que en una cadena de montaje se construyen coches… no es realista.

(Enlace a la parte 2 de este artículo: Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas (2/2))

Si te ha gustado.. compártelo!

• Acerca de
• Últimas entradas

Javier Garzás

Javier Garzás es Doctor (Ph.D) en Informática, con un
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.

Últimas entradas de Javier Garzás (ver todo)

• Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
• Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
• HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024