Lucas Ontivero

Hace una año comencé la serie Introducción a los Software Factory con 4 entradas: [Software Factories] Introducción (Parte 1), [Software Factories] Introducción (Parte 2), [Software Factories] Introducción (Parte 3) y [Software Factories] Introducción (Parte 4). 

Hoy quiero exponer los desafios que plantea la implantación de una software factory en el mundo real.

Veamos....

1. Al hablar hoy de software factories uno puede revivir el sentimiento de frustración que sentia 15 años atras cuando hablaba de programación orientada a objetos. Nadie sabe muy bien de que se trata pero en lugar de interiorizarse y comprarse un buen libro, prefieren dejar volar su imaginación y crear sus propias definiciones. Recuerdo a una profesora de la universidad inventando toda una teoría paralela mientras que alumnos atormentados se preguntaban si un caso de herencia múltiple entre una clase Hombre y otra Lobo daba por resultado un Hombre-Lobo o algún otro ser mitológico. Con los conceptos de SF hoy sucede exactamente lo mismo. 
   
   Otros confunden las clases con los objetos en el sentido de que piensan que los software factories son SCSF, WSSF, WCSF o simplemente "cosas que se hacen con VS". Es decir, no diferencian entre un conjunto particular de instancias de SFs horizontales, en este caso hechas por MS como son SCSF y WCSF, y los conceptos en los que se sustentan.
   
   Esto trae aparejado el siguiente pensamiento:
1. ¡Nooo, pero para eso falta muchísimo!. (visión developer) Esta es con total seguridad la más común y se compone de dos facciones, los que están en lo cierto (hay avances pero estamos en veremos) y los que piensan que desarrollar software con una SF es algo parecido a "tomo un módulo de ventas, se lo incrusto a este otro de stock... lo pego con dos piecitas de biztalk, lo envuelvo en este estandard y listo!!", esto es producto de las desafortunadas analogías con industrias como la automotríz o la aeronáutica las cuales son de producción y no de desarrollo.
2. ¡Es muy riesgozo y nosotros ya tenemos un proceso de producción de software!. (visión PL/PM) Esta es la misma pero con una diferencia importante: aquí es posible hablar de reducción de costos, tailorización de procesos, beneficios en el time-to-market, es decir, es mucho más sencillo traducir los conceptos al idioma de un PL que habla en $$$ al de los desarrolladores que hablan en C++. También es posible interesarlos con los casos de éxito de HP, IBM, Nokia y otros, o alinearlo con objetivos de negocios o con las iniciativas de mejora de la calidad y de reuso de software o alguna otra.
    
   
2. Si los manager entienden del tema todavia es muy dificil por cuanto se trata de una "inversión" que posiblemente no se alcance a recuperar por lo que querran estudiar el tema (lógico!). Si después de que los números los convenzan, si logran ignorar a los miedosos, deben esponsorear el proyecto de cambio que, piloto de por medio, movilizará a referentes de todas partes a tomar acciones como:
1. Tailorizar el o los procesos para adecuarlos a la manera de trabajar que se lleva en los proyectos de esa familia de productos.
2. Gestionar la comunicación interna para informar a todos los involucrados sobre la nueva manera de pensar y hacer software. Estos cambios siempre despiertan curiosidad y motivación en la gente por lo que abre las puestas para que se los involucre en las nuevas tareas. Además todo el mundo tendrá preguntas y sugerencias. Si esto no se hace lo que se generará será alguna variante del temor.
3. Seleccionar al equipo de desarrolladores que construirá  el SF. Aquí el arquitecto es pieza clave y debe tener ante todo un conocimiento muy profundo sobre el dominio.
4. etc. Digo etc. porque estos puntos y otros ya los traté en las introducción (parte 2)

En una lista de consideraciones tan escueta podemos ver que existen varias condiciones que probablemente al principio no se tenian en cuenta como que llevan tiempo y dinero y que la fase de codificación es solo una pequeña parte de la cuestión, que involucran a roles de administración de proyectos, gestión de la configuración, especialistas de testing, ingenieros de campo, desarrolladores obviamente y otros, que habrá que mantener la SF, que tendrá que capacitarse a la gente que la utilizará, que debe verse como una inversión a recuperar y que esto sucederá a medida que se vayan entregando proyectos en los cuales se hayan reducido los costos gracias a la utilización del SF, que es una apuesta a largo plazo, y otras cuantas más, pero la síntesis seria algo así como: "Creiste que era más facil ¿no?"

Existen pruebas de que esto no es facil, solo hay que ver como los distintos elementos que conforman el sistema de una SF se han ido utilizando como quick fixs que de a uno logran verdaderamente muy poco. Hay quienes todo lo pretenden resolver con un framework, otros intentan sin exito entender para qué sirven los DSLs y cual es la diferencia con los frameworks, otros utilizan VS (GAT/GAX) para verdaderas nimiedades, los procesos apenas si se alteran en algo.Pero ayer me he dado con una prueba curiosa pero contundente de que esto no es facil, al toparme con este paper de M. L. Griss del año 1993 en el que se plantea la necesidad de crear SFs, y los llama así: Software Factories. Griss comenta los casos de éxito en las iniciativas de SF de distintos monstruos de la economia. Hoy seguimos hablando de los mismos temas.

Lucas Ontivero