El problema de la integración en grandes proyectos de software

Uno de los desafíos más grandes a la hora de llevar adelante grandes proyectos de construcción de software es lograr integrar fluidamente las distintas partes en las que seguramente hemos dividido su construcción.

Hace muchos años me encontraba formando parte de un equipo de desarrollo numeroso que estaba abocado a construir un sistema en Java destinado a manejar la actividad “core” de la empresa. La construcción del sistema se estaba haciendo, obviamente, por partes y el responsable de todo el desarrollo había repartido entre distintos equipos la construcción de los módulos funcionales. 

Mi rol no era de desarrollo sino que estaba manejando temas de gestión del proyecto y testing. 

En un determinado momento, la construcción aislada de cada uno de los "silos" iba sobre ruedas (o inclusive más rápido de lo previsto) pero yo comencé a preocuparme por la integración de todas esas partes. Veía demasiado ensimismados a los grupos de trabajo y prestando muy poca atención a cómo iban a dialogar sus módulos con los demás. Mi hipótesis era que cuanto más tardásemos en abordar el tema de la integración, más difícil sería poner todo a funcionar.

A partir de eso comencé a insistir con el responsable del proyecto para hacer pruebas de integración en forma temprana. Haciendo corta la anécdota, no tuve éxito. Las pruebas de integración no comenzaron a planearse hasta después de haber terminado los módulos por separado. Al final, integrar los módulos nos demoró 3 veces el tiempo empleado para construir los módulos locales.

Esta fue la primera vez que me encontré con el problema pero no la última. He visto lo mismo en muchas otras situaciones: en desarrollos "desde cero", en implementaciones de producto(s) donde hay que realizar customizaciones, en instalación de productos que (supuestamente) sólo debe configurarse, en software que se construía utilizando las técnicas más sofisticadas de desarrollo (por ejemplo técnicas agile como TDD), etc.

La moraleja es que cuanto más grande el equipo de trabajo y mayor es la cantidad de piezas de software involucradas, más tiempo debemos destinar a la integración. A saber, definir qué integraciones habrá, definir cómo funcionarán, definir cómo se probarán, probarlas, etc.

Por último, para aquellos que quieran saber cómo se puede hacer esto, un buen comienzo es leer el ensayo “The Whole and the Parts” del libro The Mythical Man-Month de Fred Brooks.

Seguimos pensando..