Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas

Construir software no es igual que construir un puente, un edificio o un coche. Y difcilmente llegar a serlo. Porque el producto final, el software, tiene diferencias muy sustanciales con estos productos fsicos. Estas diferencias hacen que el proceso de construccin sea diferente. Y obviar estas diferencias puede implicar importantes problemas a la hora de desarrollar, planificar, gestionar, etc., un proyecto software. Diferenciar el cmo se construye el software de cmo se construyen los productos fsicos es adems uno de los pilares de las metodologas giles. Y un tema del que se ha escrito mucho; uno de los textos que personalmente ms me gustaron cuando lo le hace tiempo es la nueva metodologa de Fowler, del que se extraen muchas ideas de este post. Y tambin 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 ms razones, os dejo dos, las dos que en mi opinin son ms significativas del porqu fabricar software no es lo mismo que fabricar coches o construir casas: La diferente separacin entre diseo y construccin y la diferente distribucin de los costes del proyecto. 1 - La diferente separacin entre diseo y construccin En ingeniera software, a diferencia de en la arquitectura u otras ingenieras tradicionales, no se puede separar tan claramente la fase de diseo y de la de construccin. Las ingenieras clsicas precisan mucho de un diseo previo a la construccin, 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 construccin (los arquitectos). La construccin tiene poco componente intelectual y mucho manual. Y todo esto hace que existan dos actividades claramente diferenciadas: el diseo y la construccin. Desde sus orgenes, la ingeniera del software intent perseverantemente emular a las ingenieras clsicas. Tener una fase de diseo muy separada de la codificacin. Que la codificacin no comenzase hasta que terminase el diseo. Que el diseo concluya con unos planos precisos que guen totalmente la construccin. Que una vez que se hace un diseo 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 difcil especificar en la una nica y primera fase de diseo todas las cuestiones a tratar en la programacin. Por la complejidad de muchas de las reglas de negocio que automatizamos cuando construimos software es muy difcil saber qu software se quiere hasta que se trabaja en su implementacin. De ah que en software diseo y construccin se solapen, y que por ello que muchas veces se recomiende construir por iteraciones y el uso de prototipos incrementales. A la mayora de los diseos de las ingenieras clsicas, arquitecturas, etc., no les sucede esto porque pueden hacer un mayor uso de las matemticas, en software no es as. Y aunque se pretenda emular ese modo de fabricacin, en software no funciona bien, y debemos tener muy claro que es casi imposible cerrar un diseo a la primera para pasarlo a codificacin sin tener que modificarlo. As que, salvo que se descubra algo nuevo, el sueo de construir software igual que en una cadena de montaje se

construyen coches no es realista. 2 La diferente distribucin de los costes del proyecto. Por lo general, realizar un cambio en el producto final que construyen las ingenieras clsicas o la arquitectura es muy costoso ( $). Cambiar, por ejemplo, la posicin de una columna en un edificio o realizar modificaciones a la estructura de un puente ya construido tiene un alto coste. Y de ah que la arquitectura o las ingenieras clsicas pretendan lograr a toda costa diseos o planos de un alto nivel de detalle, que una vez que comience la fase de construccin no tengan que ser modificados. Adems, normalmente, en la arquitectura o en las ingenieras clsicas los costes de construir son muy elevados en comparacin con los de disear. El coste del equipo de diseadores es sustancialmente inferior al de la realizacin de la obra, del puente, edificio, etc. Las anteriores pautas para costes no se comportan igual en el caso del software. Por un lado, el software, por su naturaleza (y si se construye mnimamente bien), es ms fcil de modificar. Cambiar lneas de cdigo tiene menos impacto que cambiar los pilares de un edificio ya construido. De ah que existan numerosas propuestas que recomiendan construir rpido una versin software y modificarla evolutivamente (la tcnica de refactorizacin trabaja sobre esta idea). En software no existe esa divisin tan clara entre los costes del diseo y los de la construccin. Con todo lo visto, querer construir software de la misma manera a como se hace un edificio puede implicar importantes problemas a la hora de desarrollar, a la hora de planificar el proyecto, gestionarlo o incluso a la hora de poner solucin a una posible desviacin sobre el plan. Y de aqu nacen muchos de los llamados errores clsicos de la gestin de proyectos software, como el mtico hombre-mes o intentar solucionar el retraso de un proyecto aadiendo ms programadores, emulando a cuando se quiere acelerar la construccin de un edificio aadiendo ms albailes. O el pretender que las fbricas software trabajen igual que las fbricas de coches. Salvo que se en ingeniera del software inventemos algo nuevo, no construiremos software igual que en una cadena de montaje se construyen coches. Y cuanto antes todos nos demos cuenta de ello mejor nos ir en los proyectos software.

http://www.javiergarzas.com/2011/02/diferencias-software-fabricacion-tradicional-1.html http://www.javiergarzas.com/2011/02/diferencias-software-fabricacion-tradicional-2.html