Mary Poppendieck mirando en perspectiva

 En QCon Plus, una conferencia virtual de InfoQ, se presenta una conversación con Mary Poppendieck (en la charla también interviente Tom, su esposo y socio en su largo trabajo de consultoría). Mary presenta una visión de los cambios producidos en la construcción de software comenzando con el nuevo siglo: veinte años de cambios radicales que alteraron los paradigmas en que nos hemos basado por décadas. Me parece una visión en perspectiva de particular interés, considerando su propio trabajo en 3M iniciado con Six Sigma, y su propio entendimiento de los conceptos agiles. Mary habla de puentes; ella misma lo es, acompañando el cambio establecido.

Moviendo una aplicacion a la nube

 Días atrás leí con interés un artículo de Jonathon Henderson, de Scott Logic, describiendo detalladamente un proyecto de conversión de una aplicación descripta sin entrar en detalles como "monolítica", a un conjunto de servicios y/o aplicaciones back y front end que la reemplacen, basado en AWS. Henderson describe su proceso de descubrimiento y reconocimiento de los mecanismos y recursos que fue necesitando, y su proceso de entendimiento y dificultades que pudo o no resolver: una bitácora de trabajo más que útil. Esta es su descripción del proyecto:

I had the pleasure of picking up Scott Logic’s StockFlux project with the same fantastic team as my previous project, which consisted of 3, very talented frontend developers and myself as the lone backend developer.

The frontend team had the task of transforming the existing StockFlux application to use the bleeding edge of the OpenFin platform, which incorporated features defined by the FDC3 specification by FINOS.

This involved splitting StockFlux into several applications, to showcase OpenFin’s inter-app functionality such as snapping and docking, as well as using the OpenFin FDC3 implementations of intents, context data and channels for inter-app communication. It also involved using the FDC3 App Directory specification to promote discovery of our apps using a remotely hosted service, which is where I come in.

Henderson describe fundamentalmente su trabajo de backend, sin entrar prácticamente en el trabajo del frontend, pero de todas formas es una buena y estimulante descripción de aprendizaje y evaluación de caminos posibles.

Esta es su enumeración de objetivos de su propio trabajo:

• Building an FDC3 compliant App Directory to host our apps and provide application discovery.
• Building a Securities API, with a full-text search, using a 3rd party data provider.
• Providing Open-High-Low-Close (OHLC) data for a given security, to power the StockFlux Chart application.
• Creating a Stock News API.
• Building and managing our infrastructure on AWS.
• Automating our AWS infrastructure using CloudFormation.
• Creating a CI/CD pipeline to test, build and deploy changes.

Una vez completado el proyecto, con una idea clara de los puntos fuertes y débiles de su desarrollo, y del soporte de AWS, Henderson se siente conforme con lo hecho. No obstante, deja una observación que debe ser tenida muy en cuenta:

One thing I’m still relatively unsure about is the idea of vendor lock-in. By basing an application around their specific services, we effectively lock ourselves into AWS, which makes our applications less portable. While building the StockFlux backend services I made an effort to abstract things in such a way that would allow us to add support for services offered by other providers, to reduce our dependency on AWS. On the other hand, locking into one vendor doesn’t have to be a bad thing - by committing to use AWS (or another provider), we can explore and utilise the vast array of services that are on offer, rather than restrict ourselves to using as little as possible to promote portability.

Es decir, permanece casi por completo en manos de su proveedor, sus tarifas, y evolución de sus planes.Sin duda, una particularidad de Cloud services que debe ser pesada con cuidado. Especialmente cuando se translada no una aplicación pequeña y volátil, sino algo de importancia y vasto.

James Ward sobre Java

James Ward, de Salesforce, escribió el pasado mes de diciembre una  nota sobre Java (y alrededores). Una excelente lectura sobre java para aplicaciones web, y seguramente adaptable a otros escenarios. En realidad, se trata de una recomendación basada en experiencia acerca de la adopción de métodos ágiles y el recurso a herramientas de automatización y sistematización del proceso de contrucción (e implementación) de aplicaciones. No quiero repetirlo, pero sí recomendarlo. En todo caso, quisiera citar su reflexión sobre el mantenimiento de releases "monolíticos" (trabajar para entregas en series de tiempo y desarrollo prolongadas):

Monolithic Releases Suck

Unless you work for NASA there is no reason to have release cycles longer than two weeks. It is likely that the reason you have such long release cycles is because a manager somewhere is trying to reduce risk. That manager probably used to do waterfall and then switched to Agile but never changed the actually delivery model to one that is also more Agile. So you have your short sprints but the code doesn’t reach production for months because it would be too risky to release more often. The truth is that Continuous Delivery (CD) actually lowers the cumulative risk of releases. No matter how often you release, things will sometimes break. But with small and more frequent releases fixing that breakage is much easier. When a monolithic release goes south, there goes your weekend, week, or sometimes month. Besides… Releasing feels good. Why not do it all the time?
Moving to Continuous Delivery has a lot of parts and can take years to fully embrace (unless like all startups today, you started with CD). Here are some of the most crucial elements to CD that you can implement one-at-a-time:

• Friction-less App Provisioning & Deployment: Every developer should be able to instantly provision & deploy a new app.
• Microservices: Logically group services/apps into independent deployables. This makes it easy for teams to move forward at their own pace.
• Rollbacks: Make rolling back to a previous version of the app as simple as flipping a switch. There is an obvious deployment side to this but there is also some policy that usually needs to go into place around schema changes.
• Decoupled Schema & Code Changes: When schema changes and code changes depend on each other rollbacks are really hard. Decoupling the two isolates risk and makes it possible to go back to a previous version of an app without having to also figure out what schema changes need to be made at the same time.
• Immutable Deployments: Knowing the correlation between what is deployed and an exact point-in-time in your SCM is essential to troubleshooting problems. If you ssh into a server and change something on a deployed system you significantly reduce your ability to reproduce and understand the problem.
• Zero Intervention Deployments: The environment you are deploying to should own the app’s config. If you have to edit files or perform other manual steps post-deployment then your process is brittle. Deployment should be no more than copying a tested artifact to a server and starting it’s process.
• Automate Deployment: Provisioning virtual servers, adding & removing servers behind load balancers, auto-starting server processes, and restarting dead processes should be automated.
• Disposable Servers: Don’t let the Chaos Monkey cause chaos. Servers die. Prepare for it by having a stateless architecture and ephemeral disks. Put persistent state in external, persistent data stores.
• Central Logging Service: Don’t use the local disk for logs because it prevents disposability and makes it really hard to search across multiple servers.
• Monitor & Notify: Setup automated health checks, performance monitoring, and log monitoring. Know before your users when something goes wrong.

There are a ton of details to these that I won’t go into here. If you’d like to see me expand on any of these in a future blog, let me know in the comments.

Un punto importante, pero recordado sólo con el propósito de que lea completa la reflexión de James Ward, que lo merece.

Una arquitectura de dos velocidades (McKinsey)

Un par de artículos publicados por McKinsey este mes de diciembre, (1 y 2, firmados por Oliver Bossert, Jürgen Laartz, y Tor Jakob Ramsøy), plantean una estrategia realista de adaptación en una empresa anterior al universo digital. Los autores proponen una estrategia de dos velocidades para sumar una capa digital a una empresa de corte tradicional. Si lo releemos un poco, podríamos concluír que el escenario descripto es común y mayoritario: las empresas nativas digitales son una minoría, aunque se hayan convertido en hegemónicas en muy pocos años. Excelente artículo para pensar estrategias.
El postulado de los autores es este:

Unlike enterprises that are born digital, traditional companies don’t have the luxury of starting with a clean slate; they must build an architecture designed for the digital enterprise on a legacy foundation. What’s more, while most companies would have been comfortable in the past going through a three- to five-year transformation and not implementing new features in the meantime, today’s highly competitive markets no longer allow players to alter architecture and business models sequentially. It is therefore important to realize that the transformation toward digital is a continuous process of delivering new functionality.

Para los autores, esta migración al mundo digital requiere hacerse fuertes en cuatro aspectos: Innovación en el desarrollo de productos y servicios, habilidad para atender múltiples canales, capacidad de análisis de datos y tendencias (big data), automatización y digitalización de procesos de negocios:

First, because the digital business model allows the creation—and shorter time to market—of digital products and services, companies need to become skilled at digital-product innovation that meets changing customer expectations. One such new offering for consumers is car-insurance policies enabled by geolocation-tracking technology, where the price of the policy depends on how much and how aggressively a person actually drives.
Second, companies need to provide a seamless multichannel (digital and physical) experience so consumers can move effortlessly from one channel to another. For example, many shoppers use smartphones to reserve a product online and pick it up in a store.
Third, companies should use big data and advanced analytics to better understand customer behavior. For example, gaining insight into customers’ buying habits—with their consent, of course—can lead to an improved customer experience and increased sales through more effective cross-selling.
Fourth, companies need to improve their capabilities in automating operations and digitizing business processes. This is important because it enables quicker response times to customers while cutting operating waste and costs.

El problema básico al que hay que encarar es el relacionado con la contradicción entre una empresa estable, con procesos de negocios manejados de manera conservadora, frente a la necesidad de ser flexible, ágil, rápido y variable en la atención de los nuevos procesos. Esto requiere otra manera de organizar las actividades de IT:

While a few players have overcome some of these hurdles, it is a big challenge for many IT executives to implement all four levers so customers can, for instance, purchase individually tailored products across multiple channels. One important reason is that the legacy IT architecture and organization, for example, which runs the supply-chain and operations systems responsible for executing online product orders, lacks the speed and flexibility needed in the digital marketplace.
Indeed, the ability to offer new products on a timely basis has become an important compe­t­itive factor; this might require weekly software releases for an e-commerce platform. That kind of speed can only be achieved with an inherently error-prone software-development approach of testing, failing, learning, adapting, and iterating rapidly. It’s hard to imagine that experimental approach applied to legacy sys­tems. Nor would it be appropriate, because the demand for perfection is far higher in key back-end legacy systems. Quality, measured by the number of IT system errors, and resilience, measured by the availability and stability of IT infrastructure services, comes at slow speed but is critical for risk- and regulatory-compliance management and for core transactional activities such as finance and online sales. In contrast, lower IT-system quality and resilience can be acceptable in customer-facing areas, for instance, when users participate in the testing of new software. For these reasons, many companies need an IT architecture that can operate at different speeds.

Los autores valúan como imprescindibles los dos tipos de procesos (tradicionales, difícilmente transformables, y digitales, con grandes requerimientos de agilidad, flexibilidad y rapidez de respuesta). En este marco, elaboran una serie de recomendaciones para mantener e interactuar entre ambos tipos de procesos y necesidades:

Manage a hybrid target architecture with very different platforms. Digital target architectures are heterogeneous, with trans­actional platforms managed for scalability and resilience coexisting alongside other systems optimized for customer experience. The transformation can be sustained only if a high-level target architecture and standards in critical areas such as cybersecurity are clearly described from the beginning. Without them, the transformation can be slowed down by the complexity of legacy and new hardware and application provisioning.
Plan for ongoing software delivery with blends of methodologies. There isn’t time to develop software by using a waterfall model and then separating the transformation into several long phases, as in traditional multi-year IT transformations. Nor is the solution to migrate all delivery to agile methodologies. The answer is to do both but blend the benefits of agile (iterative development, continuous delivery) into the waterfall model. Now, the software solution for each business challenge has to be constantly developed, tested, and implemented in an integrated fashion. This requires clear segregation of platforms into domains managed for fast iterative delivery (for example, for customer-experience applications) or for transactional integrity (for back-end transactional systems).
Develop the low-speed architecture, too. It’s important to establish a clear distinction between the two IT models from the beginning and not only focus on the fast-speed part but also develop the transactional back-end architecture. Those systems of record require rigorous development and testing methodologies and must be managed for resilience and scalability, with no compromises.
Build a new organization and governance model in parallel with the new technology. In the digital enterprise, business and IT work together in a new and integrated way, where boundaries between the two start to blur. This partnership has to be established during the transformation^.
Change mind-sets. By transforming the architecture, technology can become a key fac­tor for a company’s competitiveness. Such a development requires increased management attention and usually a place on the board agenda. While IT efficiency clearly remains important, spending levels may well rise as companies transform IT from largely being a necessary expense to being a true business enabler. As such, expenses are managed as investments rather than just costs; this will often require a substantial mind-set shift for the organization.
Run waves of change in three parallel streams. In a two-speed transformation, it makes sense to have an implementation plan that runs in three parallel streams. The digital-transformation stream builds new functionality for the business, supported by the results of a short-term optimization stream that develops solutions that might not always be compliant with the target architecture (for example, using noncom­pliant interfaces). To ease the development of short-term measures and create a sustainable IT infrastructure, an architecture-transformation stream is the third necessary component.

Las técnicas descriptas pueden verse no sólo como aplicables a una estrategia de cambio hacia una economía digital, sino a cualquier escenario de una empresa grande, con una tradición establecida de procesos de negocios y soluciones tecnológicas establecidas pero anticuadas; la idea central que destaco de la visión de Bossert y otros es la de articular dos velocidades en el desarrollo de nuevos procesos y arquitecturas, dando a cada parte su importancia relativa, y manteniendo procedimientos diferenciados según de qué área se trate.
Recomiendo releer varias veces estos artículos, extrapolando cuando parezca necesario.

¿CMMI y Agile?

Una ácida observación de Juan Palacio sobre un giro en los conceptos de CMMI:

CMMI y PMI (organizaciones sin ánimo de lucro) están dando un volantazo hacia la agilidad que cuestiona cuál es su misión: el negocio de la consultoría o la difusión y mejora del conocimiento profesional de ingeniería de procesos y dirección de proyectos, respectivamente.

Este vender también respuesta a la demanda de agilidad y olvido de lo mucho que deberían aportar en la evolución de la ingeniería secuencial (cascada) a la ingeniería concurrente, y su aplicación en proyectos TIC, nos deja, como afirma Sandra Valle, sin referentes de información para las empresas TIC que quieren evolucionar de la ingeniería secuencial a la ingeniería concurrente, y no a la agilidad; y además nos confunde con los papers "mezcla-todo" con los que justificar porqué antes eran digo y ahora Diego.

MDD: Una polémica en castellano

Javier Garzas ha tenido la muy buena idea de transcribir en su blog una discusión que sostuviera poco antes en Twitter con otros colegas españoles, acerca del alcance y validez del desarrollo basado en modelos, y de su confrontación y validez frente al concepto "el diseño es el código". La discusión refleja entre sus lectores un gran interés en el tema, pero también un persistente desconocimiento, y además algo de desconfianza y rechazo acerca de la idea del desarrollo guiado por modelos. No tengo tiempo hoy para otra cosa que no sea recomendar su lectura y, para quienes lo crean necesario, participar en la discusión. Espero tener tiempo el fin de semana para hacer algo más que recomendar su artículo, y la lectura de los comentarios de sus lectores. Entretanto, gracias especialmente a Javier y Pedro por su gran discusión.

Mejorando los procesos...

 Quiero reunir aquí dos comentarios que leí o releí estos últimos días, que contienen observaciones fruto de la experiencia reflexiva. Y que más veces de las deseables son ignoradas.
En el primer caso, se trata de recomendaciones de Gerald Weinberg acerca del estudio del alcance de los pequeños cambios, aquellos que parecen no tener importancia...hasta que es demasiado tarde. Dice Weinberg (en inglés):

Some perfectionists in software engineering are overly preoccupied with failure, and most others don't rationally analyze the value they place on failure-free operation. Nonetheless, when we do measure the cost of failure carefully, we generally find that great value can be added by producing more reliable software. In Responding to Significant Software Events, I give five examples that should convince you.

The national bank of Country X issued loans to all the banks in the country. A tiny error in the interest rate calculation added up to more than a billion dollars that the national bank could never recover.

A utility company was changing its billing algorithm to accommodate rate changes (a utility company euphemism for "rate increases"). All this involved was updating a few numerical constants in the existing billing program. A slight error in one constant was multiplied by millions of customers, adding up to X dollars that the utility could never recover. The reason I say "X dollars" is that I've heard this story from four different clients, with different values of X. Estimated losses ranged from a low of $42 million to a high of $1.1 billion. Given that this happened four times to my clients, and given how few public utilities are clients of mine, I'm sure it's actually happened many more times.
 (...)
The Pattern of Large Failures
Every such case that I have investigated follows a universal pattern:

1. There is an existing system in operation, and it is considered reliable and crucial to the operation.
2. A quick change to the system is desired, usually from very high in the organization.
3. The change is labeled "trivial."
4. Nobody notices that statement 3 is a statement about the difficulty of making the change, not the consequences of making it, or of making it wrong.
5. The change is made without any of the usual software engineering safeguards, however minimal, that the organization has in place.
6. The change is put directly into the normal operations.
7. The individual effect of the change is small, so that nobody notices immediately.
8. This small effect is multiplied by many uses, producing a large consequence.

Whenever I have been able to trace management action subsequent to the loss, I have found that the universal pattern continues. After the failure is spotted:

9. Management's first reaction is to minimize its magnitude, so the consequences are continued for somewhat longer than necessary.
10. When the magnitude of the loss becomes undeniable, the programmer who actually touched the code is fired—for having done exactly what the supervisor said.
11. The supervisor is demoted to programmer, perhaps because of a demonstrated understanding of the technical aspects of the job. [not]
12. The manager who assigned the work to the supervisor is slipped sideways into a staff position, presumably to work on software engineering practices.
13. Higher managers are left untouched. After all, what could they have done?

The First Rule of Failure Prevention
Once you understand the Universal Pattern of Huge Losses, you know what to do whenever you hear someone say things like:

• "This is a trivial change."
• "What can possibly go wrong?"
• "This won't change anything."

When you hear someone express the idea that something is too small to be worth observing, always take a look. That's the First Rule of Failure Prevention:

Nothing is too small to be unworthy of observing.

 La segunda reflexión la hizo hoy el "tendero digital", muy oportuna, sobre los inconvenientes de la especialización en el análisis de procesos, por la pérdida de visión del conjunto del problema. Lo que "el tendero" dice:

Hoy otro tema del que ya he hablado aquí antes. Pero es que me he visto involucrado en un proyecto que cuando lo he entendido… pues eso que no me resisto contarlo y volver a reiterar una gran verdad: “La informatización por si misma, no resuelve problemas”. Y otro que podríamos ver relacionado, es la gran escasez de profesionales más generalistas y menos especialistas. Estamos en una época en la que se necesita a más gente con talentos cruzados. Personas que sean capaces de ver más de una dimensión de un solo problema. Como diría un amigo y lector del blog, necesitamos a más Leonardos y menos especialistas. En el mundo de la gestión informática, siguen faltando arquitectos, visionarios que sean capaces de tener todo el proyecto en la cabeza. No gente que da martillazos, otros que atornillan, los de allí al lado que pintan… y no ven más alla de su pequeña tarea. 
Hace ya muchos años, el Departamento donde yo trabajaba en mi empresa de por las mañanas se llamaba: “Análisis y racionalización de procesos”. Si os fijáis en el nombre, por ningún sitio aparece el nombre de informática, digital o cosas más modernas. Y también destaca en el nombre la palabra procesos. Esa era nuestra tarea y racionalizar un proceso no significaba automáticamente hacer un programa de ordenador, eran muchas más cosas.  Era el tiempo en que todavía trabajábamos con pantallas de fósforo naranja de 9 pulgadasy pico (ostias como una tablet cualquiera, éramos ya visionarios). Con el paso de los años nos fueron cambiando el nombre (y también las funciones) y ahora somos Desarrollo, así sin más. Que por cierto no desarrollamos ya nada, pero eso sería otra historia (jugosa, pero para otro día)
Bueno, me dejo de introducción. Me llaman el otro día para plantearme unas dudas de un proyecto. Les contesto y les digo que puedo preparar unos ejemplos de carga para lo que están haciendo y que lo prueben, pero que se puede hacer y además es sencillo. Mientras prepara los ejemplos, empiezo a no entender algunas cosas (o entenderlas demasiado bien). Así que miro quien ha pedido el proyecto y lo llamo. Después de un buen rato, se confirman mis temores. Y me doy cuenta que después de 20 años, volvemos al principio. En la época de las pantallas de fósforo, teníamos muchos procedimientos, que obligaban a capturar los datos en papel y enviarlos a un centro de grabación de datos. Allí donde si tenían PCs o terminales más grandes que uno de 9”, pues traspasaban la información del papel al sistema informático. Estuvimos casi un lustro hasta que al final pudimos matar ese tipo de procesos. Recuerdo lo felices el día en que por fin pudimos eliminar la toma de datos en papel y conseguir que con la primera captura de datos en el PC, todo el sistema funcionara. Lo que me estaban pidiendo, era volver al sistema anterior con una sola diferencia, los que escribían en papel y cargaban en sus terminales eran empresas externas. Pregunté si alguien se había planteado los costes del proyecto, si alguien sabía porque la primera captura de datos no nos servía… y todo fue encogimiento de hombros. Pregunté si la persona de la empresa externa conocía bien lo que estaba haciendo, si teníamos seguridad con los datos en papel. No supieron que contestarme.
 Nadie piensa en racionalizar los procesos. Entre otras cosas, porque no hay nadie que vea el proceso como un todo. Cada uno ve su parte y la hace sin preguntar. Como en cada paso hay un especialista, pues éste solo resuelve su parte, nadie se plantea el conjunto, el proceso completo y global. Además como todo el mundo tiene formación técnica, pues la solución es impecable desde ese punto de vista, pero es un despropósito desde la racionalización y ahorro de tiempo. Pero esa parte no preocupa, no sale en los seguimientos. Lo que preocupa es que la petición entro el día d, el día d+15, ya teníamos el análisis y el día d+45 tendremos una versión de pruebas. Y luego el día d+60 estará en real. Como hemos cumplido las fechas todo ha sido un éxito. Que lo que hemos creado sea más feo y más dispar que el monstruo de Frankestein,  eso no importa y que sea más difícil de montar y entender que un mueble de Ikea tampoco…

 Todos conocemos incidentes como estos...

SPLC 2011

Con programa preliminar a partir de este domingo, el lunes y martes próximo se desarrollará en Munich la 15ª conferencia de Lineas de Producto Software (SPL, Software Product Lines). Un concepto fundamental en la construcción de software, una fuente de ideas para quienes lo construyen, tanto sea en grandes unidades económicas, donde sus conceptos deberían ser  irremplazables, como para unidades menores, donde deberían motivar líneas de investigación y trabajo más racionales.
Aunque hemos conversado más de una vez sobre su significado, la descripción de uno de sus tutoriales explica razonablemente su meta:

Product Line Engineering is a common approach to address a business with a family of related software products. Instead of having separated development projects for each product in the family, products are built using a shared set of core assets, such as reference architectures and common infrastructure and domain-specific components. Key drivers for PLE are the potential cost savings due to shared core assets, as well as new business opportunities by, for instance, supporting tight integration and improved interworking among members of the product family. 

 Estoy persuadido de que SPL y MDD recorren caminos convergentes y retroalimentados. Uno de los tutoriales que se desarrollarán, toca esta característica: "Leveraging Model Driven Engineering in Software Product Lines", desarrollado por  Bruce Trask and Angel Roman:

Model Driven Engineering (MDE) is a promising recent innovation in the software industry that has proven to work synergistically with Software Product Line Architectures (SPLA). It can provide the tools necessary to fully harness the power of Software Product Lines. The major players in the software industry including commercial companies such as IBM, Microsoft, standards bodies including the Object Management Group and leading Universities such as the ISIS group at Vanderbilt University are embracing this MDE/SPLA combination fully. IBM is spearheading the Eclipse Foundation including its MDE tools like the Eclipse Modeling Framework (EMF) and the Graphical Modeling Framework. Microsoft has also launched their Software Factories and DSL Toolkit into the MDE space. Top software groups such as the ISIS group at Vanderbilt are using these MDE techniques in combination with SPLAs for very complex systems. The Object Management Group is working on standardizing the various facets of MDE. All of these groups are capitalizing on the perfect storm of critical innovations today that allow such an approach to finally be viable. To further emphasize the timeliness of this technology is the complexity ceiling the software industry find itself facing wherein the platform technologies have increased far in advance of the language tools necessary to deal with them. This complexity ceiling is evident in today’s Software Product Lines.

 Invito a seguir sus sesiones, a solicitar sus presentaciones, y a tomar contacto con sus participantes. Estas conferencias anuales acercan el mejor material sobre el tema.

Información y seguimiento en el sitio de la conferencia.

Sugerencias que da un proyecto

Bob Fields, de Walt Disney World, comenta en The Model Driven Software Network, la  estrategia de la compañía para el desarrollo de sus aplicaciones usando Java, Eclipse, Rational, Maven. Una experiencia que recién comienza a describir, pero que ya presenta aspectos de interés si la sobrevolamos un poco, sea en general como medio de articular una línea de trabajo con MDD, o, siendo más específico, desde el punto de vista de Plex. Dice Bob:

(...) My main passion as an architect is in finding ways to improve the software development process through automation. I have championed the adoption of Apache Maven at WDPR, but much work remains before we have full adoption and integration over all phases of the lifecycle.(...) I led the effort to adopt an MDA tool several years ago. After investigating a number of alternatives (two no longer exist: OptimalJ and ArcStyler), we settled on the open source tool AndroMDA because of the maven implementation plus the mature output capabilities using velocity templates: Java, Spring, Hibernate, EJB, EJB3/JPA, Struts, JSF, WebServices, jBPM/Drools, dotNet NSpring/NHibernate/ASP.

 Es decir, articular una herramienta MDD con el mayor espectro posible de salidas, incluyendo todo en algún tipo de herramientas que permita articular y automatizar cuanto sea posible del ciclo de vida del sofware. En el caso de Plex, muchas sugerencias para extender y abrir el desarrollo, adelantándose a lo que en un momento determinado sea posible hacer con la IDE. Lo que iniciara Webclient (puente con Eclipse + Web), ampliado.

Otra compra en el mercado de ALM

Un mes antes que MKS, también Aldon cambia de dueños. En un mes, dos viejos competidores pasan a ser parte de la cartera de empresas que participan del mercado de ALM (application lifecycle management), pero con un alcance más general. Ahora es Rocket Software quien absorbe a otro actor de gran alcance en el manejo de administración de cambios en el iSeries. Parecería ser que los márgenes en el mercado del iSeries (y del ALM seguramente) han disminuído convirtiendo en inviables a productos de un sólo perfil...o por lo menos, más fáciles de tentar con un cheque. Un argumento más en favor de considerar a ALM como un commodity.
El anuncio en SystemI Network, y en la propia Rocket.
También a Rita Sanders la noticia pare caerle por sorpresa:

I stumbled onto the news when I went looking for details on Seagull Software, which I hadn't heard any news from in quite some time. The application modernization vendor's website reminded me that it, too, had been purchased by Rocket Software back in 2007, and is operating as Rocket Seagull, another Rocket Software business unit.
I chatted briefly on Friday with a Rocket Software spokesperson, and he said Rocket Software's growth is a question of the company building its product portfolio in four areas: business intelligence and analytics; storage, networks, and compliance; application development, integration, and modernization; and database servers and tools.

PTC compra MKS

Otro cambio de manos en la industria del software: PTC compra MKS, la empresa canadiense dedicada a herramientas de manejo de ciclo de vida del software. MKS es (o fue) un actor importante en el mercado de iSeries (o AS400, o System i, o como se llame), a través de Implementer y otras herramientas asociadas. A su vez, Implementer fue un producto comprado a Silvon (1998), diseñador originario del producto. MKS con esa compra integró una cartera de productos orientados al soporte del  ciclo de vida de desarrollo de software, que fuera el núcleo de su actividad desde su inicio. Su desaparición (o absorción, para ser más exacto) concentra un poco más la industria, como viene sucediendo desde el 2000 aproximadamente.
Aunque de esto hace ya algunos años, he tenido contacto con la empresa, que heredó, con la compra a Silvon de Implementer, el producto de administración de cambios (MKS-CM Connector) para 2E (hoy CA 2E). Su cambio de propietario traerá cambios de estrategias y partidas en el personal (diseñadores, ingenieros, comerciales) que harán su futuro un poco más anónimo y genérico. Es que ALM es un mercado de commodities...
Para los seguidores de Plex y 2E, CM First, base de Webclient, soporta un producto de administración de cambios para el iSeries (Matchpoint) que también deberá reacomodar sus cargas ante el cambio de guardia de uno de sus competidores.

Ralph Johnson sobre el software complejo

Una breve reflexión de Ralph Johnson sobre el colapso del software complejo:

Clay Shirky had a blog about the collapse of complex business models.  He referred to a book by Joseph Tainter called "The Collapse of Complex Societies" that I put on my must-read list.  The book describes why societies collapse, and implies that it is necessary.  Clay says the same thing about the collapse of complex business models; there is no way for the old companies to adopt the new business model, so they will eventually collapse along with their old business model.  Naturally, I thought about software.  Is there any way to save complex software when it needs to change and can't?   We can refactor it, throw parts away, reuse parts of it.  But is that any different from what collapsing societies do?

Lo relacionaremos en otro momento con el ciclo de vida de los ERPs...

Apuntes sobre Factorías de Software,III

Quisiera cerrar un comentario de hace un año sobre factorías de software. El tema surgió, como se dice en la primera nota, de un incidente ya superado con la definición del concepto en Wikipedia. Aquel incidente inicial me motivó a conversar con algunos colegas en el interés de aportar una definición más adecuada que la que en un momento tuvo. De esas conversaciones surgió un borrador que nunca llegó a integrarse a Wikipedia, dado que el problema que lo motivara dejó de existir. Sin embargo, el borrador quedó, y estas sucesivas notas publican lo que todavía pudiera ser de interés.
Entonces, para cerrar ese documento, se despliegan ahora los dos o tres puntos de algún interés y de los que aún no se haya hablado...
Cusumano sobre la industria japonesa
Dice Cusumano sobre la industria japonesa del software, para el período 1970/90, reconociendo diferencias entre procesos a los que se puede aplicar un estilo de factoría de software, y aquellos donde no es adaptable:

As for the future of Japanese-style factories as a way of organizing software development (and perhaps other types of design and engineering work), it remained possible that large centralized factory organizations represented a transitional stage in the evolution of Japan's approach to managing software development technology.
Between the late 1960s and the early 1990s, the factory initiatives provided a useful mechanism to centralize, study, and manage a series of projects more efficiently than treating each effort as separate, with scale economies restricted to individual jobs and no scope economies systematically exploited. With improvements in electronic communications technology, it was no longer essential to concentrate large numbers of people in single locations, as seen in the NEC and Fujitsu cases, although Hitachi and Toshiba managers clearly preferred to bring people together, and it seemed more likely that factory-like organizations would continue to co-exist with job shops, depending on the kind of software being built as well as company objectives.
In general, factory strategies appeared best suited for software systems that could rely on reusable designs and components as well as common development tools and techniques. For totally new or innovative design efforts, Japanese software producers tended to utilize less structured organizational forms, such as special projects, laboratories, or subsidiaries and subcontractors, that gave individual engineers more freedom to invent and innovate. To the extent that Japanese firms wished to place more emphasis on individual creativity, they were likely to build more software in non-factory environments as well as emphasizethe design and engineering roles of personnel in internal projects, especially since new engineering recruits in Japan seemed to prefer labels other than "factory" to describe their places of work.
(Cusumano, Shifting Economies: From Craft Production to Flexible Systems and Software Factories, pag 46)

Reflexiones de Aaen,  Bøtcher y Mathiassen sobre flexibilidad
Del trabajo de Ivan Aaen, Peter Bøtcher y Lars Mathiassen (Software Factories), mencionado al inicio de esta serie, quisiera destacar el enfoque abierto de su investigación:

The term factory signals a commitment to long-term, integrated efforts—above the level of individual projects—to enhance software operations. This is not only a powerful, but also a necessary idea taking the challenges involved in professionalizing software operations into account. But for many the term factory has at the same time the controversial connotation that software development and maintenance is comparable to mass-production of industrial products, and arguably this is not the case. This can easily lead to illusions with respect to the kinds of interventions that can, in fact, improve software operations. It is not surprising, therefore, that some software professionals like the concept while others do not.
The term factory can be used to denote either one or more buildings with facilities for manufacturing or the seat of some kind of production. To many people the concept of a factory also implies a particular way of organizing work with considerable job specialization,formalization of behavior and standardization of work processes.
In this paper we will not adopt this historically based connotation. Rather we use the term without assumptions regarding particular ways to standardize, formalize, specialize, or achieve functional
grouping. The factory is an organization inhabited by people engaged in a common effort, work is organized one way or the other, standardization is used for coordination and formalization, and systematization is important, but there will be several options for the design of a particular software factory. This paper investigates how existing approaches to the software factory has chosen among such options by fitting each approach into one of Henry Mintzberg’s five basic organizational structures (Mintzberg, Structures in Fives: Designing Effective Organizations, Prentice-Hall 1983): the simple structure (organic, centralized, direct supervision); the ad-hocracy (organic, decentralized, mutual adjustment); the machine bureaucracy (bureaucratic, centralized, standardized processes); the professional bureaucracy (bureaucratic, decentralized, standardized skills); and the divisionalized form (decomposed based on standardized output).
(...)The goal is to clarify useful contributions and possible illusions related to the idea of a software factory.
(... ) We agree with Cusumano that the challenge for software management is to find ways to “improve organizational skills—not just in one project but across a stream of projects. To accomplish this, however, and still meet the demands of customers, competitors, and the technology itself, requires firms to balance two seemingly contradictory ends: efficiency and flexibility” (Cusumano 1991, p. 5).
The inherent complexities involved in developing and maintaining software suggest that the appropriate organizational form for a software operation is the professional bureaucracy in which professional competence is viewed as more important than standardized procedures and advanced technologies. Software managers are therefore advised to view the professional bureaucracy as the ideal and dominant form while elements of the machine bureaucracy and other organizational forms (Mintzberg 1983) should be treated as supplements to cope with variations, to increase efficiency whenever industrialized procedures are feasible, and to allow for greater flexibility in unique situations where existing procedures and experiences are insufficient. For this reason any long-term management commitment to improve software operations should fundamentally be based on approaches focusing on software processes, (...) and view approaches focusing on infrastructure as supplementary strategies that can help develop environments in which processes and professionals are better supported.

Algunas líneas sobre fuentes reconocidas
Dos fuentes generalmente reconocidas sobre el tema, y con toda razón, son Michael Cusumano y Yoshihiro Matsumoto, citados y analizados por prácticamente todos los autores leídos. Luego, Michael Evans y Herbert Weber, todos ellos a fines de los ochenta o comienzos de los 90. Probablemente influídos por los estudios de estos autores, Hitachi, Toshiba, Fujitsu, el proyecto Eureka y el proyecto Thales son algunos de los más mencionados y analizados. Desde finales de los noventa, es CMM el conjunto de recomendaciones más analizado. En los últimos años se advierte una evolución de estos trabajos a investigaciones orientadas a desarrollo basado en modelos y a los conceptos de Lineas de Producto Software (SPL), que en general no se han comentado en estos apuntes, aunque sí en infinidad de otros.

En cuanto a obras básicas sobre Factorías, estas son algunas de ellas:

Cusumano, M. A. (1989): The Software Factory: A Historical Interpretation. IEEE Software, Marzo.
Cusumano, M. A. (1991): Japan’s Software Factories. Oxford University Press.
Matsumoto, Y. (1981): SWB System: A Software Factory. En H. Hunke (Ed.): Software-Engineering Environments. Amsterdam: North-Holland.
Matsumoto, Y. (1987): A Software Factory: An Overall Approach to Software Production, En P. Freeman (Ed.): Software Reusability, IEEE.
Matsumoto, Yoshihiro y Ohno, Yutaka, “Japanese Perspectives in Software Engineering”, Addison-
Wesley Publishing Company, 1989.
M. Paulk, B. Curtis, M. Chrissis and C. Weber, Capability Maturity Model for Software (Version 1.1),
Technical Report, CMU/SEI-93-TR-024, Pittsburgh, Software Engineering Institute, Carnegie Mellon
University, Febrero, 1993.
Weber, Herbert, (editor), “The Software Factory Challenge - Results of the Eureka Software Factory
Project”, IOS Press, 1997.
Michael W. Evans, The software factory: a fourth generation software engineering environment,John Wiley & Sons.
Un antecedente que en su momento apuntó Pedro Molina correctamente, es Parnas:
D. Parnas: On the Design and Development of Program Families. IEEE Transactions on Software Engineering, March 1976, antecedente también de SPL.

Algunos papeles leídos en el curso de esta recopilación, han sido:
Concepto y Evolución de las Fabricas Software, Javier Garzás, Mario Piattini
Software Factories, de Ivan Aaen, Peter Bøtcher y Lars Mathiassen.
Improving MDD Productivity with Software Factories, de Benoît Langlois, Jean Barata, y Daniel Exertier
Making the Software Factory Work: Lessons from a Decade of Experience, de Harvey P. Siy, James D. Herbsleb, Audris Mockus, Mayuram Krishnan y George T. Tucker
Diffusing Software-based Technologies with a Software Factory Approach for Software Development, A Theoretical Framework, de Lim, Ngang-Kwang, Ang, S. K. James, y Pavri, F.N.
Otros de Cusumano y Matsumoto han sido mencionados antes.

Testeando Plex

John Rhodes publicó hace pocos días una presentación sobre un producto promovido por ADC Austin para testear aplicaciones de Plex y 2E (Certify). Más allá de su aspecto comercial, de especial utilidad para quienes utilizan Plex (o 2E), dada la dispersión de soluciones asumidas en este terreno.
Pueden encontrarse otras similares en Slideshare. Una referencia a la empresa creadora de Certify (Worksoft), en su sitio.

Un caso de uso de desarrollo basado en modelos

Fred Madiot publicó hace pocos días una breve reseña del paso a diseño basado por modelos en un caso práctico: un banco tunecino que decide reelaborar sus aplicaciones cambiando tecnología y método de construcción. Nada mejor que casos prácticos para que quienes se aproximan a conocer el desarrollo basado en modelos, tengan una idea del estilo y posibilidades de MDD.
Para mi experiencia y preferencias, de todas formas esperaría que cada caso (aquí, el proyecto del banco) requiriera menos elaboración (me refiero a que el modelado se centrara más en la aplicación, y no inicialmente en la herramienta de transformaciones), y que el código se derivara sin fase final manual, desde un generador bajo Eclipse:

From the EMF model of the reference application, the templates have regenerated 6 MXML files and 19 ActionScript files (Commands, Events, Service Delegates, Front Controller, and Value Objects). The MXML files contain the graphical definition of the GUI: they will be generated only once, just to provide a first application which can be executed. Then they will be edited and maintained with a WYSIWYG designer.

Este aspecto revela en mi criterio la todavía relativa inmadurez de las herramientas disponibles. Digo esto desde mi punto de vista, con una herramienta, Plex, que considero más consistente en este terreno, y a la vez menos flexible en el mismo aspecto que estoy observando.
En común: en la comunidad de Plex, la importancia de Eclipse como puente entre las reglas de Plex y el ancho mundo de los metamodelos para resolver lo que no esté contemplado.

Fred Madiot también participa del proyecto MoDisco, que intenta desarrollar herramientas capaces de extraer el modelo implícito en una aplicación antigua (Legacy Reverse Engineering), de lo que hemos hablado en alguna oportunidad.

Modelos y libertad de acción

Jean-Jacques Dubray escribió, el once de este mes, una "carta abierta a Steve Jobs", en la que, a propósito de la declaración de Apple de que cerrará la programación para el iPhone, recuerda su catastrófica experiencia con NeXTStep, el revolucionario sistema operativo que Jobs desarrolló en su transitoria etapa fuera de Apple. Dubray recuerda su decidido compromiso por el sistema operativo y sus herramientas, y cómo la absorción posterior de NeXT por Apple destruyó su inversión, y afectó a sus clientes:

I discovered NeXT and NeXTStep in 1990 at Penn State and it was love at first sight. I was inspired, from the very first second after years of programming in Turbo Pascal. It is hard to believe for most people that something like Xcode was available as early as 1989. I had built two solutions with NeXTStep: a Laboratory Information Management System (LIMS) and an Industrial Process Control System. It was not easy but the results were incredible.

NeXTStep was so productive that a very small team of 2 or 3 people could write software that was vastly superior to the one written by much larger teams (10-50). I still remember a professor from Stanford visiting us at Hughes Research Lab and looking at these two products (at the time I had also added a Natural Language Interface to the Process Control Software to log process data in the LIMS and define control rules), his jaw dropped on the floor.

Yet, around 1994, NeXT started to fail. You had already moved to create OpenStep (a port of their APIs to Sun -yet incompatible with NeXTStep) and all together in 1997, NeXTStep was packed in boxes and moved to Apple. It resurfaced nearly a decade later. You can easily imagine how these two "strategic" moves impacted my business and my customers. Yes, devastating doesn't really qualifies.

La enseñanza que sacó Dubray de su experiencia tiene dos aspectos: uno, respecto a la evolución de la industria del software, que no necesariamente coincide con los intereses del usuario de la tecnología:

Software vendors are always looking for new customers, they compete against each other and ultimately they have no commitment to their past customers. I actually don't know a single Platform Software Vendor which understands and focuses on helping their existing customers migrate to new versions of their platform. They simply don't care, older customers are just collateral damage.

Su segunda conclusión es que ya nunca encarará la construcción de software comprometido técnicamente con un proveedor, sino que se apoyará en el desarrollo basado en modelos:

I have learned my lesson, never, ever will I write code directly tied to a set of APIs.
(...) NeXT shaped my mind to build model-driven software. Somehow, I could never go back to just writing imperative code ever again. Around 2005, my understanding of MDE became a lot more formal with the emergence of DSL Tools and Eclipse Modeling Framework and later XText and Oslo.
Ever since I understood how deadly, and frankly stupid it was to tie your solutions to vendor APIs, I spent lots of time developing strategies to become technology and architecture independent.

Jean-Jacques expresa un punto de vista importante en el estado actual del mercado del software: en un universo de negocios cambiantes, donde la tecnología es infinitamente variada, y donde es difícil contruír soluciones estables porque el ciclo de vida de las aplicaciones es crecientemente corto, comprometerse con una solución basada en una tecnología es peligroso. Y orientarse hacia el desarrollo basado en modelos es preventivo: difícilmente un cambio de tecnología afectará la especificación del software. Existen distintas variantes de desarrollo basado en modelos; cualquiera de ellas ofrecerá mejores perspectivas que un diseño apegado a un lenguaje, o infraestructura, o plataforma específica. En el estado actual de la industria, cada variante de lenguaje o plataforma se acerca a ser un commodity, y es el desarrollo basado en modelos el que permite manipular esta diversidad.

Los cambios que Borland y Google implican

Martinig, haciendo un resúmen del 2009, apunta dos hechos que miden el cambio en curso en la industria del software: la desaparición de Borland (entre otras), y el crecimiento en el alcance de Google:

Sobre Borland (Bye, Bye, Borland):

After the sale of its development tools division to Embarcadero in 2008, Borland kept only the tools dealing with requirements management and software testing. This didn’t improve its financial situation and finally Borland sold itself to MicroFocus. This was a sad end for a brand that accompanied software developer for more than 25 years. Software requirements have always been a secondary topic in the software development tools world and the trend towards agility hasn’t improved this. Now you can manage user stories with paper cards and a board. Approaches like UML are declining and you will find few items dealing with them in today’s programmers waterhole like dzone.comstackoverflow.com, The end of Borland is just the symptom that this world is difficult for requirements tools vendors.

Sobre Google (Google is (also) a Software Development Tools Company)

Google domination in the search engine world is well known, but as far as developers are concerned, it is amazing how Google is quietly occupying more and more space. Here are some of the software development initiatives of Google:
* Google App Engine
* Google Web Toolkit GWT
* Go Language
* Google open source projects forge
* Google I/O Conference

Google seems to have understood that besides the content, it should also be active in the plumbing that runs the Web. This is why software developers should be interested in what Google does in this area. You could do this following some blogs like the Google Code BlogGoogle Testing Blog. You will see that besides the well-known projects, Google releases a lot of interesting open source tools created by its development team.

Criticas a UML

Steven Kelly, a comienzos de octubre, destacó un estudio de W.J. Dzidek, E. Arisholm y L.C. Briand, (publicado en IEEE Transactions on Software Engineering, Vol 34 No 3, de Mayo/Junio de 2008), acerca de la eventual productividad de UML en el mantenimiento de una aplicación. El objetivo del estudio era medir y comparar el rendimiento de UML generando código a partir de un modelo, versus un equipo programando en Java. Un segundo aspecto de mucha importancia era que este proyecto se desarrollara como mantenimiento, no como desarrollo desde inicio. Es decir, cada equipo debía modificar distintos aspectos de una aplicación existente y documentada, en lugar de desarrollar desde cero y sin condicionamientos.
El experimento no deja muy bien parado a UML, que da diferencias a favor no muy grandes, a condición de excluír los tiempos de actualización de los diagramas. El equipo programando en Java logra mantenerse bastante cerca de los tiempos del equipo que trabaja con UML.
Estos son los aspectos que destaca Steven, comprometido con Metaedit, una de las herramientas orientadas a Domain Specific Languages mas consolidadas en el mercado, que considera revalidada su afirmación sobre el uso de UML: "empirical research shows that using UML does not improve software development productivity".
Las observaciones de Steven sobre la validez del experimento son atinadas:

One bad thing about the article is that it tries to obfuscate this clear result by subtracting the time spent on updating the models: the whole times are there, but the abstract, intro and conclusions concentrate on the doctored numbers, trying to show that UML is no slower. Worse, the authors try to give the impression that the results without UML contained more errors -- although they clearly state that they measured the time to a correct submission. They claim a "54% increase in functional correctness", which sounded impressive. However, alarm bells started ringing when I saw the actual data even shows a 100% increase in correctness for one task. That would mean all the UML solutions were totally correct, and all the non-UML solutions were totally wrong, wouldn't it? But not in their world: what it actually meant was that out of 10 non-UML developers, all their submissions were correct apart from one mistake made by one developer in an early submission, but which he later corrected. Since none of the UML developers made a mistake in their initial submissions of that particular task, they calculated a 100% difference, and try to claim that as a 100% improvement in correctness -- ludicrous!

To calculate correctness they should really have had a number of things that had to be correct, e.g. 20 function points. Calculated like that, the value for 1 mistake would drop by a factor of 20, down from 100% to just 5% for that developer, and 0.5% over all non-UML developers. I'm pretty sure that calculated like that there would be no statistically significant difference left. Even if there was, times were measured until all mistakes were corrected, so all it would mean is that the non-UML developers were more likely to submit a code change for testing before it was completely correct. Quite possibly the extra 15% of time spent on updating the models gave the developer time to notice a mistake, perhaps when updating that part of the model, and so he went straight back to making a fix rather than first submitting his code for testing. In any case, to reach the same eventual level of quality took 15% longer with UML than without: if you have a quality standard to meet, using UML won't make you get there any more certainly, it will just slow you down.

Queda por ver cuánto influyó en el resultado la elección de la herramienta usada (Borland Together for Eclipse), y si otro modelador hubiera mejorado los números. Sin embargo resulta notable encontrar tanta proximidad entre uno y otro equipo. Sigue pareciendo que hacer pasar todo el desarrollo del modelo por los tipos de diagramas hoy existentes, es insuficiente. Esta es una discusión reiterada en The Model Driven Software Network, tanto en conversaciones anteriores (1, 2, 3), como en la misma que se abriera sobre este experimento.

Por mi parte, quisiera agregar a las observaciones de Steven una más:
El experimento se propone actuar sobre un modelo "en movimiento", para evitar crear un caso de condiciones ideales, en las que, arrancando de cero, se contruye una solución limpia. Sin embargo, al partir de un desarrollo prolijo, estandarizado, bien documentado, está creando un ambiente de laboratorio. Nunca la comparación entre un desarrollo basado en un modelo y un desarrollo basado en código directo (digamos 3GL) será así: en la medida que un desarrollo basado en modelos y otro equivalente basado en código evolucionen, la oscuridad del diseño crecerá, y probablemente lo hará en forma exponencial, siendo mayor el diferencial cuanto más tiempo y actores hayan pasado. Si trabajamos con un diseño de seis meses de antiguedad, las diferencias en opacidad serán no muy grandes; pero si la aplicación tiene dos, tres, cuatro años, y por ella han pasado dos o tres oleadas de desarrolladores, indudablemente será más productivo trabajar con un modelo que navegando y apostando porque el cambio que hagamos no estalle por otro lado.
En el estudio se omite que un trabajo basado en código fuente directo estará expuesto a distintos estilos de grupos o personas intervinientes, que puede tener callejones sin salida, parches, y aún fraudes o sabotajes. De ninguna manera, sobre una aplicación compleja, los tiempos de trabajar a través de un modelo podrán ser iguales a los tiempos que se tomarán haciéndolo sobre el código mismo. Y mucho menos si las personas acaban de ser contratadas para esa tarea, como pretende hacerlo el experimento.
Esto sin introducir alguna variable independiente, como por ejemplo, un cambio de versión en software de infraestructura o de framework que afecte a la aplicación.
Como siempre, debo aclarar que no uso UML en mi actividad diaria. Sin embargo, prefiero extender el alcance de las críticas al uso de herramientas de modelado en general. Soy conciente que Steven no se pronuncia a favor del código fuente, porque él lo ve desde el campo del desarrollo basado en modelos, pero compara UML contra DSLs. Este es otro asunto, que merece tiempo aparte. Pero creo que es necesario dejar bien claro que el concepto genérico de desarrollo basado en modelos es indudablemente superior al uso de código directo, y mayor cuanto más complejo sea el caso. De lo que se trata es de encontrar una fórmula para expresar de manera flexible y ágil la conducta dinámica de un modelo, algo que UML no parece resolver de manera satisfactoria todavía. ¿Existe solución? Sin duda que la habrá. En mi caso, por lo menos, una solución existe. Pero eso será también aparte.

Apuntes sobre Factorías de Software, II

De lo comentado antes, queda la impresión de que durante la época temprana del desarrollo del software, múltiples líneas de acción tendieron a darle sustento sistemático a su concepción y construcción, y en este contexto, la idea de aplicar el concepto de factoría fue una vía consistente de trabajo; primero iniciada en Estados Unidos, luego tomada con fuerza por Japón, y finalmente continuada en Europa. Tanto M. Cusumano como Y. Matsumoto señalan la conferencia de la NATO sobre Ingeniería de Software en 1968, como el punto de partida de los intentos de construír el software a modo de una factoría desde la Ingeniería de Software.
Ya se habló de Bob Bemer y M.D. Mcllroy, cuyos antecedentes se remontan a fines de los 60, y cuyas afirmaciones van en el sentido de mejorar procesos y procedimientos, medir, estandarizar herramientas de productividad, y establecer técnicas de reutilización del código.
Cusumano recoje a Mcllroy sobre reutilización de código, tan temprano como 1968:

The most important characteristic of a software components industry is that it will offer families of routines for any given job. No user of a particular member of a family should pay a penality, in unwanted generality, for the fact that he is employing a standard model routine. In other words, the purchaser of a component from a family will choose one tailored to his exact needs. He will consult a catalogue offering routines in varying degrees of precision, robustness, time-space performance, and generality. He will be
confident that each routine in the family is of high quality--reliable and efficient. He will expect the routine to be intelligible, doubtless expressed in a higher level language appropriate to the purpose of the component, though not necessarily instantly compilable in any processor he has for his machine. He will expect families of routines to be constructed on rational principles so that families fit together as building blocks. In sort, he should be able safely to regard components as black boxes.

[Citado por Cusumano en The Software Factory: Origins and popularity in Japan: M.D. Mcllroy, "Mass Produced Software Components," in Peter Naur and Brian Randell, eds., Software Engineering: Report on a Conference Sonsored by the NATO Science Committee, Brussels, Scientific Affairs Division, NATO, January 1969]

En este y otros papeles, Cusumano recoje a Bemer sobre métricas y factorías:

[A] software factory should be a programming environment residing upon and controlled by a computer. Program construction, checkout and usage should be done entirely within this environment, and by using the tools contained in the environment... A factory... has measures and controls for productivity and quality. Financial records are kept for costing and scheduling. Thus management is able to estimate from previous data... Among the tools to be available in the environment should be: compilers for machine-independent languages; simulators, instrumentation devices, and test cases as accumulated; documentation tools -- automatic flow-charters, text editors, indexers; accounting function devices; linkage and interface verifiers; code filters (and many others).

[Cusumano, en The Software Factory: Origins and popularity in Japan: R.W. Bemer, "Position Papers for Panel Discussion -- The Economics of Program Production," Information Processing 68, Amersterdam, North-Holland, 1969, pp. 1626-1627]

Objetivos semejantes impulsaron el desarrollo de las fábricas de software de Hitachi, Toshiba, NEC, Fujitsu, a partir de la década de 1970, y las de SDC de Rand Corporation en Estados Unidos. Estas acciones fueron analizadas detalladamente por Michael Cusumano, que entrega también una buena bibliografía sobre los esfuerzos dedicados desde los 60 hasta los 90. Particularmente destaca el trabajo de Matsumoto en Toshiba:

An RD group responsible for industrial systems software in Toshiba, led by Dr. Yoshihiro Matsumoto, introduced an organization and process in 1977 integrating tools, methods, management and personnel systems with a physical layout for work stations (...). The strategy for utilizing this infrastructure centered around four policies: (1) standardize the development process, to reduce variations among individuals and individual projects; (2) reuse existing designs and code when building new systems, to reduce redundant work and maximize productivity; (3) introduce standardized and integrated tools, to raise the performance levels of the average programmer; and (4) provide extensive training and career-development tracks for programmers, to relieve the shortage of skilled engineers.

Perhaps the most delicate feature of Toshiba's Factory was its organizational structure, a matrix imposed over product departments from several operating groups and divisions, all located on one site, Toshiba's Fuchu Works. Established in 1940 and set on 198 acres in the western outskirts of Tokyo, the Fucnu Works in 1991 had at least 8000 employees working primarily in four areas: Information Processing and Control Systems, Energy Systems, Industrial Equipment, and Semiconductors (Printed Circuit Board Division). Operating departments within the divisions corresponded roughly to 19 product lines, including systems for information and control in public utilities, factories, power-generation plants, and various industrial and transportation equipment. Each department contained sections for hardware and software design as well as for manufacturing, testing, quality assurance, and product control.

Similarities in the type of software the Fuchu Works built from project to project allowed Toshiba to deliver "semi-customized" programs that combined reusable designs and code with newly written modules, rather than writing all software from scratch. Toshiba also relied heavily on a standardized tool and methodology set, the Software Engineering Workbench (SWB), developed gradually after 1976and modelled after AT&T's UNIX Programmers Workbench. Toshiba utilized its customized version of the UNIX operating system as well as a full complement of tools for design-support, reusable module identification, code generation, documentation and maintenance, testing, and project-management. Important features of the Toshiba methodology were the design of new program modules (ideally limited to 50 lines) for reusability, the requirement that programmers deposit a certain number of reusable modules in a library each month, and the factoring in of reuse objectives into project schedules and budgets (Matsumura et al., 1987).

Software productivity at the Toshiba Software Factory rose from 1390 delivered equivalent-assembler source lines or EASL per person per month in 1976 to over 3100 in 1985, while reuse levels (lines of delivered code taken from existing software) increased from 13% in 1979 to 48% in 1985. The 3130 lines of EASL source code per month per employee translate into approximately 1000 lines of Fortran, the most common language Toshiba used in 1985 -- considerably more than the 300 lines or so of new code per month commonly cited for U. S. programmers making similar real-time applications. Quality levels (defined as the number of major faults detected after final testing) also improved dramatically after the opening of the factory, ranging from 7 to 20 per 1000 lines of delivered code converted to EASL to .2 to .05 in 1985 (the range depended on quality-control practices as well as the reliability requirements and the amount of testing customers contracted for) (Cusumano, 1991: 240).

Toshiba data indicated that reusability was the major reason for productivity and quality improvements. The organization Toshiba created to promote reuse and overcome short-term concerns of project managers and development personnel (such as the longer time required to write and document reusable software) relied on Software Reusing Parts Steering Committees and a Software Reusing Parts Manufacturing Department and Software Reusing Parts Center. The factory formed a steering committee for different areas (with different members, depending on the application) to determine if customers had a common set of needs suitable for a package, and then allocated funds from the Fuchu Works' budget for these special projects. Some packages were usable in different departments, although most served specific applications. The Reusing Parts Manufacturing Department and Parts Center evaluated new software (and documentation) to make certain it met factory standards; after certification, engineers registered the software in department or factory reuse
databases (libraries). Registered items required a key-word phrase to representthe functionality of the part or correspond to a specific object, as well as reuse documentation that explained the part's basic characteristics.
[Cusumano, The Software Factory: An Entry for the Encyclopedia of Software Engineering]

Al documento mencionado en la nota anterior, se agregan otros tres consultados del mismo autor, todos en el mismo sentido:

The Software Factory: Origins and popularity in Japan, Cusumano, Massachusetts Institute of Technology (MIT), Sloan School of Management, Working Papers (WP2036-88)

A quantitative analysis of U.S. and japanese Software-Engineering practice and performance, Cusumano y Chris F. Kemerer, en Management Science, Volumen 36 , número 11, 1990

The Software Factory: An Entry for the Encyclopedia of Software Engineering, Cusumano, Massachusetts Institute of Technology (MIT), Sloan School of Management, Working papers, (WP3268-91)

En resumen, las décadas de los 80 y 90, en estos y otros papeles, se revelan como un laboratorio precursor tratando de elevar la productividad especialmente en la industria japonesa: un aspecto fundamental es el papel motor de sus empresas, y la colaboración con instituciones de investigación universitaria. De paso, merecen un comentario aparte (será otro día) las observaciones de Cusumano sobre las diferencias de enfoque entre Japón y Estados Unidos.
Visto en perspectiva, este esfuerzo por plasmar factorías de software colaboró, junto a otras líneas de acción, a prefigurar áreas de investigación que ya nos son mucho más familiares: el impulso del análisis y diseño orientado a objetos, y el desarrollo de componentes. Digamos que desde el punto de vista histórico, las factorías están lejos de representar un retroceso en la forma de encarar la construcción de software. Matsumoto por ejemplo, muestra en la continuidad de su propia actividad cómo este pensamiento siempre estuvo en primera línea de la investigación acerca de mejores vías para la construcción de software.

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.