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!

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

  1. Totalmente de acuerdo! 🙂
    Y hay otro problema que recalca esto, y es que el software no se puede simular.
    Cuando diseñas un puente, puedes simularlo en un programa que te calcula qué fuerzas aguantará, verlo construido en 3D, etc… en el software eso es imposible. La simulación de un software es su propia construcción.

  2. Antonio Manuel Martínez Heredia

    Muy bueno el post,
    tienes mucha razón, pero es muy díficil pensar en el desarrollo de un producto (sw) cuando la persona con la que hablas no tiene familiariedad con este tema.

    1. Concuerdo, si una personas no tiene conocimientos previos, va hacer un percance a la hora de crear (SW), quedando sin tiempo o trazando el proyecto que va a necesitar mejoras.

  3. Pingback: Eventos en Abril: Semana de la Informática de Valencia | Javier Garzás

  4. Pingback: “Deadly Sins”, o “walking deads”, de implantar una metodología software. (1/2) Tres “walking deads” desde la experiencia. | Javier Garzás

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

  6. Pingback: ¿Qué es lo más determinante para el éxito, o fracaso, de un proyecto? Las personas - Javier Garzás, sobre calidad software y otros temas relacionados

  7. Pingback: Diagramas Gantt cómo arma de destrucción masiva de proyectos. Maneras de usar un Gantt para matar un proyecto - Javier Garzás, sobre calidad software y otros temas relacionados

  8. Pingback: Lean de la vida misma de un proyecto: los desperdicios del lean software (1/2) - Javier Garzás, sobre calidad software y otros temas relacionados

  9. Pingback: Ciclos de vida para gestionar un proyecto software: cascada, espiral, iterativo, incremental o ágil - Javier Garzás | Javier Garzás

  10. A pesar de que en el software se han buscado cambios alternativos a la rigidez en la planeación clásica de ingeniería, debemos tener en cuenta que este oficio es relativamente nuevo y que tiene por tanto todas las oportunidades para apalancarse en las lecciones aprendidas de las ramas mas antiguas de la ingeniería. Por ahora no funciona, pero a medida que se vayan refinando los procedimientos se optimizarán los procesos para tener diseños mas cercanos a la realidad.

  11. Son muy acertadas tus razones y concuerdo en la parte donde mencionas el software por su naturaleza, la cual se construye mínimamente bien, para realizar cambios y no tener que gastar un gran presupuesto en cambiar la posición de un pilar.

Deja un comentario

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

Share This
Ir arriba