La metáfora de la construcción y la programación

0

Este fin de semana he tenido una conversación por twitter, si es que se puede llamar conversación a dos tweets. Al poco tiempo ha surgido la indignación habitual de algunos por comparar el desarrollo de software con la construcción y la arquitectura. Y hemos entrado también en la comparación con la industria.

No ha tardado en aparecer una entrada al blog de Javier Garzas, indicando que no es lo mismo fabricar software que construir casas o fabricar coches. Citando una frase de ese artículo que resume el resto del contenido:

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.

La justificación de esta afirmación recae en que en las ingenierías clásicas hacer un cambio de diseño una vez empezada la construcción es catastrófico, y que además en la fase de diseño puede tenerse claro todo al detalle. Mientras que en desarrollo de software estas dos afirmaciones son falsas.

Si ya me conocéis de leer el blog, sabréis que no me quedo en la superficie y tengo que escarbar, escarbar y escarbar, hasta encontrar petroleo. ¿os venís conmigo?

Si el río suena es porque agua lleva

¿Por que se usan estas metáforas? Pues por lo mismo que se usa cualquier metáfora sin ánimo artístico: para explicar algo desconocido comparándolo con algo conocido. Un ejemplo lo tenéis en este artículo de Infiniteck. Usa la metáfora de construir una casa, con tomar decisiones sobre tecnología en una empresa.

Vamos al grano: el motivo principal de esta metáfora esta en los Muggles. Los Muggles no tienen ni idea de programación, ni de sistemas, ni de nada relacionado. No entienden ni entenderán nunca conceptos con los que los programadores lidian día a día. Y tampoco entenderán conceptos estratégicos del mundo TI como por ejemplo: Arquitectura SOA, aplicaciones en Cloud o utilizar un bus de servicios. Pero, sea por lo que sea, los gestores de TI tenemos que lidiar con muggles todos los días. Los clientes y las áreas de negocio están dominados por Muggles. Y muy probablemente tu jefe o el jefe de tu jefe sea un muggle. Es raro que el CEO de una empresa tenga conocimientos técnicos como para entender lo que le explican desde TI sin traducir. Así los gestores muchas veces nos vemos avocados a tener que usar metáforas.

En los comienzos de TI, el conocimiento de los muggles del mundo de la informática era nulo. Para ellos era magia. La mayoría ni siquiera había tocado un ordenador. Así eran completamente muggles. Hoy en día esto está cambiando. Los ordenadores están en todas las casas (y en los teléfonos), y a la gente corriente ya no le suena tan raro todo este mundo. Pero siguen siendo Muggles y siguen sin entender muchas cosas.

Así, cuando les tenemos que explicar algo, cuesta mucho. Y una manera fácil es acudiendo a las metáforas. ¿Qué hay que pueda entender un muggle para poder explicárselo? Pues lo más parecido son otras ingenierías o la metáfora de la construcción. Puede no ser exacta, pero para explicarle algo a un muggle puede servir.

El paso del tiempo y la pérdida de validez

Al principio estas metáforas eran perfectamente válidas. Pero con el paso del tiempo, han empezado a perder validez. Primero porque los desarrollos de software han dejado de gestionarse como otras ingenierías, con lo que la cantidad de parecidos sobre su gestión han desaparecido. Por otro porque las tecnologías han evolucionado para eliminar dependencias. Antes, un cambio en un elemento base provocaba cambios en toda la aplicación. Era como hacer un cambio en los cimientos de la casa (¡ala! que bien me sirve la metáfora), que provoca cambios en toda la casa para amoldarse a la nueva base. Hoy en día en cambio se puede cambiar de base de datos sin llegar a tocar el resto de la aplicación. Se puede cambiar una librería por otra, tocando sólo un par de puntos. Antes, cambiar de librería podía significar repasar todo el código.

Lo que más ha cambiado es el coste de un cambio, que se ha reducido; y de cómo los equipos de desarrollo se han adaptado a esto, permitiendo los cambios. Lanzándose a desarrollar antes de haber acabado el diseño. A plantear entregas iterativas. De repente la metáfora comienza a flaquear.

Cambiando la metáfora

Yo creo que el problema está en comparar la fabricación de un producto (o de una casa) con la programación. Veamos el ciclo de vida para crear un nuevo producto (con una ingeniería tradicional).

  • Diseño producto: Se diseña el producto. Se enumeran las necesidades que se tienen, los costes que se deberían tener, restricciones principales, … y se hace un esbozo de lo que tendría que ser.
  • Prototipo: Se fabrican los prototipos. Se diseña y fabrica un prototipo. Se prueba, y si algo no gusta, se desarrollan otros prototipos.
  • Diseño producción: Con el prototipo final, se diseña el proceso de fabricación.
  • Producción: Comienza la fabricación y comercialización del producto.

Estas cuatro fases normalmente se han asociado al desarrollo (en la metáfora) como que las tres primeras eran las de toma de requisitos, diseño y planificación y la última la de programación. Creo que ahí radica el error. Creo que la comparación debería hacerse como:

  • Diseño de producto: Toma de requisitos, análisis funcional, diseño técnico.
  • Prototipo: Programación.
  • Diseño producción: Preparación de entornos y preparación para puesta en producción (manuales, procedimientos, …)
  • Producción: Operaciones TI.

Olvidémonos de la parte de producción, y enfoquémonos en las primeras fases. Programar, si lo queremos comparar con una ingeniería sería como crear un prototipo. Se hace un primer diseño de lo que se quiere, puede ser más amplio o menos, y luego se hace un prototipo. Podemos hacerlo intentando que el primer prototipo sea el definitivo (gestión clásica) o plantearnos hacer prototipos cada vez más complejos hasta llegar al producto final (gestión iterativa). La metáfora en este caso encaja mucho mejor.

Y si nos vamos a la construcción, olvidémonos de la parte de construir. No caigamos en comparar el poner ladrillos con programar. Programar es más parecido a toda la parte de la generación del proyecto de arquitectura. Construir un edificio tiene dos partes: El proyecto de arquitectura y la construcción. ¿Cómo se plantea el proyecto? Pues el arquitecto jefe, toma los requisitos, los analiza y termina esbozando unos planos. Dicta materiales principales y cuatro guías importantes. Luego, una tropa de arquitectos, arquitectos técnicos y otros perfiles, comienza a bajar esas primeras ideas a la realidad. Hay que calcular estructuras, ver donde van a pasar, calcular costes, pasar suministros (agua, electricidad, comunicaciones, …) y mil cosas más. Toda esta parte es parecida a la de programar. La puedes hacer toda del tirón (a riesgo de que te tiren el proyecto al final) o ir entregando fases al cliente (haciendo un desarrollo iterativo). De hecho es normal presentar los esbozos. Y a medida que el proyecto avanza, se va cerrando cada vez más con el cliente, haciendo entregas parciales.

Es una metáfora, no un paralelismo completo

Antes de que los puristas se me echen al cuello. Hablamos de una metáfora. Tiene sus fallos. Necesitamos una manera de explicar a los muggles las cosas, y estas metáforas pueden ser muy valiosas para esto. Por supuesto que no todo es válido al 100%, pero eso no quita que no las podamos usar.

Por supuesto, si las decisiones se toman por muggles, que se basan en la metáfora y nada más, pueden llegar a conclusiones incorrectas (como las que comenta Javier Garzas). Así que hay que tratar las metáforas con cuidado. Pero eso no quita que en muchas ocasiones sean útiles.

  • Analista Funcional: Necesitaríamos saber por encima el modelo de datos
  • Negocio: Bueno, vayamos tirando y luego te los confirmamos.
  • AF: Hay cosas que las debemos tener claras al principio o podría tener mucho coste cambiarlas.
  • N: ¿No desarrollabais por sprints y no era necesario tener todos los requisitos?
  • AF: Es como al diseñar un prototipo de un coche. Te preguntaré cuantas ruedas tiene que tener. Si me dices 4, y al tercer prototipo me dices 6, a lo mejor todo el trabajo hecho en los prototipos anteriores se pierde.

Creo que tardaría menos así, que explicando que si el modelo de datos me provocará cambios en la capa de negocio y en las pantallas, y que puede tirarme el diseño técnico al suelo…

Conclusión

Creo que la metáfora es válida si se usa para explicar un concepto en el que haya paralelismo. Pero hay que tener cuidado, porque si la metáfora se usa para tomar decisiones sin entender la industria del desarrollo de software, puede llevar a equivocaciones.

 

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información.
Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector.
Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo.
Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios