Papeles sueltos sobre factorías de software

A partir de un incidente con la definición en Wikipedia para Software Factories (en ese momento, la única versión publicada de factorías de software) durante mayo de 2008, comencé a recopilar materiales sobre el tema, con la idea de consensuar con otros colegas una mejor, que abarcara lo que realmente designa el concepto. Durante unos meses reuní papeles, pero las dificultades de todos los participantes hizo que fueran quedando sin modificaciones. Pasando el tiempo, la propia razón que motivara el trabajo desapareció parcialmente, ya que, debido a las críticas levantadas por el artículo inicial, así como por el trabajo de depuración de los administradores de Wikipedia, el artículo fue desdoblado en una versión principal que habla del concepto histórico y de negocios de las factorías, y una segunda interpretación que se dedica al concepto de Jack Greenfield y Microsoft.
Para quien no hubiera visto el contenido original, motivo de polémica, una versión elemental se puede encontrar en The internet Archive, 2006 y 2007.
En fin, además de habernos permitido un trabajo reflexivo sobre el tema, también pudimos ensayar las facilidades de Google Docs (versionamiento, trabajo colaborativo).
Ahora, para cerrar el tema (o no), van aquí papeles y acotaciones surgidas durante estos meses que pueden tener algún interés para valorar las fábricas de software.
Las fuentes: tres publicaciones fueron la base para trabajar: Concepto y Evolución de las Fábricas de Software, de Mario Piattini (que revisó también el trabajo en curso) y Javier Garzás; Software Factories, de Ivan Aaen, Peter Bøtcher, Lars Mathiassen; y Shifting Economies: From Craft Production to Flexible Systems and Software Factories, de M.A. Cusumano. Los tres documentos fueron de mucho interés; los dos primeros proponiendo definiciones basadas en el estado actual, y Cusumano analizando la historia.

Las factorías de software son vistas con cierta animadversión en muchos casos, asimilándolas al establecimiento de un sistema de producción taylorista; en la discusión sobre la misma definición que en éste momento existe en Wikipedia, uno de los intervinientes afirma:

The concept of a software factory is not related to libraries within any IDE, or even the factory design pattern; but rather the organizational implementation of composite application building software engineering concepts. A software factory is a business operations concept of developing software applications through assembling components per specification. It utilizes assemblers, like any factory, who specialize and repeat their assigned tasks. This means that software is made primarily by unskilled labor, rather than engineers. It's more closely related to WYSIWYG web-pages built in DreamWeaver than anything that requires an understanding of code. Unlike that example, however, it implies a a job-floor filled with unskilled labor performing specialized tasks using tools that are designed to facilitate their jobs. You don't need the conveyor-belt maker, the torch engineer, or even a master welder, to repeat a single specific weld all day on cars moving through a factory. Likewise, not everyone involved in the software development process needs to be a software engineer. All they need are an understanding of their job, and useful tools. The requirements gathering, component/tool engineering, and similar jobs are handled elsewhere. The reason I know this is because I worked at a company with a software factory that quickly churned out fully functional applications. They used serious assembly tools and a set of components that meant no one had to even know how to read code

Esta es probablemente una realidad en muchos casos, particularmente para aquellas factorías construídas en países que explotan las grandes diferencias de costo, cuya principal actividad es el outsourcing de empresas localizadas en el otro extremo del mundo: son frecuentes las quejas de los contratantes sobre problemas de comunicación y entendimiento, y sobre la real calidad del proceso usado. Quejas frecuentes para empresas radicadas en India, por ejemplo. Sin embargo, la lectura de Cusumano, y de trabajos precursores de las décadas de los 70, 80 y 90, acercan las investigaciones sobre factorías, a los intentos por formalizar, medir, optimizar, las vías empleadas para la construcción del software. Sin negar la realidad de la visión anterior, es este aspecto, también existente desde su desarrollo temprano, el que ofrece más interés, y el que les da valor a las factorías desde el punto de vista de la ingeniería de software. Bob Bemer, McIlroy, a finales de los 60, proponen trabajar sobre la actividad de medición, mejora de la calidad de los procesos, reusabilidad, utilización de herramientas de productividad. Hitachi y Toshiba, durante la década de 1970, trabajaron ampliamente forjando herramientas y procedimientos de mayor calidad y consistencia, lejos de la imágen del taylorismo de factorías de software dedicadas a obtener contratos con el menor presupuesto posible. Una revisión del progreso del concepto a través de los finales del siglo anterior, muestra una estrecha relación entre la idea de factoría de software y las investigaciones que fueran forjando principios de la ingeniería de software. En buena medida, la idea de CASE, componentes, y la orientación a objetos, aparecen en papeles que relacionan los dos mundos. Más recientemente, la idea de Software Product Lines aparece claramente relacionada con las factorías de software. Hace algún tiempo, y en el curso de esta tarea, se ha comentado aquí el trabajo de Matsumoto, largamente vinculado al desarrollo de factorías, desde la organización de sistemas de producción hasta el desarrollo de líneas de producto. Nada de todo esto da la idea de una visión taylorista del negocio, salvo para aquellos que todavía creen que es posible el desarrollo del software como una artesanía, ni parecería que una organización de este tipo fuera posible con un equipo reducido de planificadores inteligentes, y una masa de ensambladores no calificados.
Fin por hoy. Volveremos sobre esto, quizá analizando bibliografía visitada.

Fotos: Yoshihiro Matsumoto, Michael Cusumano, Bob Bemer.