search
top

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.. compartelo!

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

  1. Joserra dice:

    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. Anonimo dice:

    200% de acuerdo, pero a ver quien se lo cuenta a mi jefe.

  3. Antonio Manuel Martínez Heredia dice:

    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.

  4. Guardiola dice:

    @Antonio Manuel Martínez Heredia:

    La cuestión no es que otros se crean que es así o no se lo crean, la cuestión es que la fabricación de software es así lo crean o no. Que bonito me quedó.

  5. Javier Escacena dice:

    Estoy de acuerdo en las diferencias con las ingenierias clásicas pero también creo que existen similitudes que si las tuviéramos en cuenta a todos nos iría mejor. Adjunto tiras de comic que aclaran perfectamente de lo que estoy hablando:
    http://www.softqatest.net/wp-content/uploads/2012/09/1.jpg
    https://scontent-b-cdg.xx.fbcdn.net/hphotos-frc3/523357_10151156196417438_528582906_n.jpg

    Salu2!

  6. ibaok dice:

    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.

  7. Jose Huerta dice:

    Hola Javier, te cojo el testigo (que lleva ya unos años ahí) y, sin dejar de estar de acuerdo contigo, salgo en defensa de la metáfora.
    http://gestionati.es/gestion/proyectos/la-metafora-de-la-construccion-y-la-programacion

Trackbacks/Pingbacks

  1. Eventos en Abril: Semana de la Informática de Valencia | Javier Garzás - [...] la sesión del viernes hablaré acerca de la evolución de la visión del desarrollo software y sus diferencias con…
  2. “Deadly Sins”, o “walking deads”, de implantar una metodología software. (1/2) Tres “walking deads” desde la experiencia. | Javier Garzás - [...] se cree aquello de que el software siempre se debe construir en cascada, y que todo lo que no…
  3. 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 - [...] (Enlace a la parte 1 de este artículo: Dos razones por las que fabricar software no es lo mismo…
  4. ¿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 - [...] La gente que participa en un desarrollo software, no son como obreros en una cadena de montaje. No son…
  5. 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 - [...] Pienso que, en parte, la razón de su gran uso en el mundo del desarrollo software viene de la…
  6. 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 - [...] se ha adaptado al software, donde las cosas no son exactamente iguales (recuerda aquello de que fabricar software no…
  7. Ciclos de vida para gestionar un proyecto software: cascada, espiral, iterativo, incremental o ágil - Javier Garzás | Javier Garzás - [...] naturaleza es lineal, típica de la construcción de productos físicos (lo comentamos en dos razones por las que fabricar…

Dejar una respuesta

Tu dirección de correo electrónico no será publicada.

top