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


(Enlace a la parte 1 de este artículo: Dos razones por las que desarrollar software no es lo mismo que fabricar coches o construir casas (1/2))
2 – La diferente distribución de los costes del proyecto.
Por lo general, realizar un cambio en el producto final que construyen las ingenierías clásicas o la arquitectura es muy costoso (€ $). Cambiar, por ejemplo, la posición 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 ingenierías clásicas pretendan lograr a toda costa diseños o planos de un alto nivel de detalle, que una vez que comience la fase de construcción no tengan que ser modificados. Además, normalmente, en la arquitectura o en las ingenierías clásicas los costes de construir son muy elevados en comparación con los de diseñar. El coste del equipo de diseñadores es sustancialmente inferior al de la realización 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 mínimamente bien), es más fácil de modificar. Cambiar líneas de código tiene menos impacto que cambiar los pilares de un edificio ya construido. De ahí que existan numerosas propuestas que recomiendan construir rápido una versión software y modificarla evolutivamente (la técnica de refactorización trabaja sobre esta idea). En software no existe esa división tan clara entre los costes del diseño y los de la construcción.
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 solución a una posible desviación sobre el plan. Y de aquí nacen muchos de los llamados “errores clásicos” de la gestión de proyectos software, como el “mítico hombre-mes” o intentar solucionar el retraso de un proyecto añadiendo más programadores, emulando a cuando se quiere acelerar la construcción de un edificio añadiendo más albañiles. O el pretender que las fábricas software trabajen igual que las fábricas de coches.
Salvo que se en ingeniería 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.
(Enlace a la parte 1 de este artículo: Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas (1/2))
Si te ha gustado.. compartelo!

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “Dos razones por las que desarrollar software no es lo mismo que fabricar coches o construir casas (2/2)”

  1. Pingback: Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas (1/2) - Javier Garzás, sobre calidad software y otros temas relacionados

  2. Hola Javier. He seguido muchos de sus artículos y le agradezco por su tiempo y dedicación. Muchas gracias por la información. Un saludo desde Bogotá, Colombia.

  3. Interesante articulo, sin embargo discrepo con las conclusiones debido a que no se está tomando en cuenta que la construcción del software es un proceso inter-disciplinario, al igual que la construcción de edificios, el Arquitecto no es un Ingeniero Civil, son profesiones separadas, y el principal problema en la construcción de aplicativos es que el Ingeniero de Software muchas veces quiere fungir de Ingeniero de Procesos, y si no se conoce realmente como es el proceso tampoco se sabrá que es lo que se quiere informatizar, por eso las marchas y contra marchas en un proyecto informático. Saludos.

  4. Buenas tardes Javier:
    He empezado a seguir su blog hace unos días y no puedo estar más de acuerdo con los errores mencionados. No sé si el origen es solo de proyectos de construcción/ingeniería pero parece que en España ante la gestión de un posible retraso, la solución es añadir más colaboradores…aún en un muro hay que dejar que el cemento seque y/o testear un programa antes de tirar más código.
    Saludos.
    Camilo (Madrid)

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *