A veces, la repetición de un término produce una sensación de familiaridad con la expresión, aunque no sepamos exactamente qué significa. Algo así sucede actualmente con el concepto de “Fábricas de Software” o “Software Factories” (SF en adelante). Hoy estas empresas son omnipresentes; en Google se encuentran de a cientos de miles. Las hay de todos los tamaños, con 4 empleados o 5000, locales o globales, para clientes corporativos o pequeñas empresas. Lo que muchas veces uno no termina de entender es ¿Qué define a una factoría de software? O mejor dicho ¿Qué la diferencia de una empresa productora de software? ¿Existe tal diferencia, o, como ha sucedido con tantos viejos términos, viene a desbancar el anticuado “empresa de software”, como “verdum” reemplaza a ensalada?
En una primera aproximación, la diferencia entre un “taller de software” o “software shop” y una SF suena sutil, pero veremos que no lo es. El taller de software es una empresa (grande o chica, no importa) dedicada a la construcción de software en forma “artesanal” ¿Porqué decimos artesanal? El término Fábrica de Software remite directamente a la forma de producción que propone la revolución industrial. Hagamos un poco de historia. En el siglo XVIII se produce un movimiento histórico llamado revolución industrial que consistió básicamente en un cambio de los métodos de producción. Antes de esta revolución existían grandes talleres, donde trabajaban maestros artesanos que poseían el saber para construir un objeto -por ejemplo una silla- de principio a fin. El artesano cortaba la madera, le daba forma, la ensamblaba, ponía el tapizado, etcétera, hasta que la silla estaba terminada. Este manufactura, como podrán imaginarse, era lenta y cara; por eso casi todos los objetos previos a la revolución industrial son objetos de lujo, que sólo podían ser adquiridos por miembros de la nobleza (¿les suena algo en relación al software artesanal?). Hilando mas fino, el proceso que tiene lugar durante la revolución industrial es el estudio del saber a los artesanos, su sistematización y su aplicación a los mecanismos de producción disponibles en la época (líneas de producción, máquinas a vapor). Este proceso permite que las sillas puedan construirse en masa y así abaratar costos y garantizar un proceso repetible ¿Cómo se aplica esta idea a la construcción de software? Básicamente, se trata del mismo concepto: un taller de software produce aplicaciones en forma única, ensamblándolas de principio a fin. Las aplicaciones pueden estar hechas a medida (específicas para un cliente) o en forma de productos, lo distintivo es que entre los productos existe un alto nivel de aislamiento, no existe la “línea de producción”. Si bien los equipos que trabajan en cada proyecto pueden compartir gente, prácticas y hasta algunos componentes, ésta metodología no se encuentra institucionalizada. Así, las iniciativas de reutilización reducen a esfuerzos individuales que casi no influyen en la producción como un todo. En general, este tipo de proyectos dependen de la pericia y la buena voluntad de la gente que los componen, de la misma manera, en el artesanado, una buena silla dependía del individuo que la había construido. Un buen equipo garantiza que el proyecto estará dentro de ciertos estándares de calidad, incluso sin una estructura que los respalde. En el taller se trabaja “ad-hoc”, es decir, para cada proyecto particular. El nivel de reutilización, en el mejor de los casos, es bajo y depende de que la gente del equipo conozca y adapte componentes usados con anterioridad. Entonces surge nuevamente la pregunta ¿Qué es y cómo se construye una fábrica de software?
El tamaño no importa
Para decirlo brevemente, una SF no se define por su tamaño pero sí por la escala a la que apunta cuando diseña sus productos. Así como una fábrica de autos, la SF basa su operación en líneas automatizadas de producción que le permiten ahorrar en términos de costo por producto ¿Cómo hace esto una SF? Una fábrica de software construye líneas de producción de software. Y éstas, a su vez, engendrarán varios sistemas que responderán a lo que esa línea fue diseñada para crear. Así, la apertura de un proyecto nuevo no implica cada vez empezar de cero, porque existe una cantidad de conocimiento que ya ha sido capturado en la línea y se puede volcar sistemáticamente a la resolución del problema. De esta manera, el team de desarrollo puede enfocarse estrictamente en la problemática particular de esa solución, ya que los aspectos genéricos (por ejemplo: la interfaz gráfica, cuestiones de autenticación y seguridad, persistencia de datos) ya fueron previstos y resueltos por la línea de producción. Imaginen, por ejemplo, que una empresa automotriz cada vez que proyecta un nuevo auto tenga que volver a desarrollar cada uno de sus componentes. De nuevo hacer un motor desde el plano, un carburador desde cero, paneles, vidrios, frenos, etc. Literalmente estaría reinventando la rueda en cada nuevo producto. Los autos tardarían años en ser desarrollados y tendrían innumerables fallas (probablemente más que ahora). Además, valdrían millones de dólares, ya que la inversión para desarrollar cada modelo desde la nada sería descomunal.
En la SF lo que cambia es el ámbito de la solución a la que se apunta. Esto implica que se diseñará, no una solución específica a un problema (por ejemplo, para manejar la contabilidad de la rotisería “El pollo bonito”) sino una solución más amplia, aplicable a un espectro de productos. Esto implica pensar en generalizaciones del tipo ¿Qué características pueden compartir todos los sistemas de gestión contable? Esto es una característica importante de una línea de producción, resolver problemas generales de un tipo de software, elevando así el nivel de abstracción de la solución. La otra característica fundamental, es establecer abundantes puntos de extensión en nuestra línea. Si bien la SF, efectivamente va a estar preparada para resolver problemas, también va a dejar “cabos sueltos”, es decir, mecanismos de personalización de la solución, ya que es muy probable que los productos necesiten modificar los comportamientos por defecto que la línea previó ¿Y esto como se hace? Un mecanismo muy utilizado es construir un potente framework extensible, un tema que fue tratado por un excelente artículo de Diego Dagum. Vayan, léanlo, yo los espero acá (…).
Para ir cerrando, armar una SF implica tomar una serie de decisiones sobre arquitecturas, modelos, prácticas y procesos a seguir con el objetivo de aplicarlos a la construcción, no de uno, sino de varios paquetes de software. Cuanto más mejor, así el retorno por la inversión se agranda. En este artículo quise reunir algunas reflexiones iniciáticas sobre las SF, para entender un poco más profundamente para qué sirven, cómo funcionan, y despejar un poco la niebla que los departamentos de marketing suelen echar sobre temas técnicos. En un próximo artículo comentaré algunas impresiones sobre la visión de Greenfield y Short (arquitectos de Microsoft), expuesta en su libro: Software Factories Assembling Applicacions with Patterns Models, Frameworks, and Tools. Estos muchachos van a fondo con esta visión y nos muestran la punta del ovillo para plasmar en resultados estos jóvenes conceptos.
Comentarios