Frederick Brooks: muere un pionero

 

Hace pocos días, el 17 de noviembre, ha muerto Frederick Brooks, un pionero de la ingeniería de software, casi de su primera generación. Longevo, continuó trabajando vinculado a las tecnologías digitales hasta la primera década de este siglo, comenzando desde 1953, después de egresar de la Universidad de Duke. Pasó por IBM a partir de 1956 y hasta 1965, donde dirigió el diseño de los ordenadores 360 (IBM System/360), el primer mainframe de IBM, base de la arquitectura estructurada por IBM, y padre directo de los 4300 y los actuales System Z. Todavía hoy una aplicación codificada en y para el 360 puede ejecutarse en un System/Z. En las decisiones que permitieron esta evolución, uno de los pilares fue Brooks. 

El otro gran aporte de Brooks está en la metodología, en la sistematización de su experiencia en sus años de IBM, en primer lugar, en 1975, con The Mythical Man-Month, y años después, en 1986, con No Silver Bullet—Essence and Accident in Software Engineering, agregado luego como nuevo capítulo en The Mythical...Existe un gran salto entre las épocas en que escribió estos libros y su lectura actual, pero a pesar del desfase técnico, todavía deben ser libros de lectura obligatoria. 

Lo que sigue es el obituario de Shane Hastie en InfoQ, con un buen conjunto de referencias a los logros de Brooks:

Dr Frederick P Brooks Jr, originator of the term architecture in computing, author of one of the first books to examine the nature of computer programming from a sociotechnical perspective, architect of the IBM 360 series of computers, university professor and person responsible for the 8-bit byte died on 17 November at his home in Chapel Hill, N.C. Dr Brooks was 91 years old.

He was a pioneer of computer architecture, highly influential through his practical work and publications including The Mythical Man Month, The Design of Design and his paper No Silver Bullet which debunked many of the myths of software engineering.

In 1999 he was awarded a Turing Award for landmark contributions to computer architecture, operating systems, and software engineering. In the award overview it is pointed out that

Brooks coined the term computer architecture to mean the structure and behavior of computer processors and associated devices, as separate from the details of any particular hardware implementation

In the No Silver Bullet article he states:

There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.

Quotations from the Mythical Man Month:Essays on Software Engineering permeate software engineering today, including:

• Adding manpower to a late software project makes it later.  
• The bearing of a child takes nine months, no matter how many women are assigned.
• All programmers are optimists.

On April 29, 2010 Dilbert explored the adding manpower quote.  

In 2010 he was interviewed by Wired magazine. When asked about his greatest technical achievement he responded

The most important single decision I ever made was to change the IBM 360 series from a 6-bit byte to an 8-bit byte, thereby enabling the use of lowercase letters. That change propagated everywhere.

He was the founder of the Computer Science Department at the University of North Carolina at Chapel Hill, where the Computer Science building is named after him. In an obituary the University says:

Dr. Brooks has left an unmistakable mark on the computer science department and on his profession; this is physically recognized by the south portion of the department’s building complex bearing his name. He set an example of excellence in both scholarship and teaching, with a constant focus on the people of the department, treating everyone with respect and appreciation. His legacy will live on at UNC-Chapel Hill

His page on the university website lists his honours, books and publications.

The Computer History Museum has an interview of Dr Brooks by Grady Booch.

He leaves his wife of 66 years Nancy, three children, nine grandchildren and two great-grandchildren.

 

DSLs en su lugar

Una "vieja" entrada del blog de Bertrand Meyer, necesaria de recordar cuando se habla de DSLs (Domain Specific Languages) con alguna liberalidad: en ocasiones se los propone para resolver problemas específicos  que parecen condenados a bufurcar el camino de trabajo. La posición de Meyer es radical: ¿cuándo crear un lenguaje de dominio? Nunca:
El contexto:

It is a common occurrence in software development. Someone says: “We should design a language”. The usual context is that some part of the development requires a rich functionality set, and it appears appropriate to provide a flexible solution through a specialized language.

La objeción de Meyer:

Designing a language in such a context is almost always a bad idea (and I am not sure why I wrote “almost”). Languages are endless objects of discussion, usually on the least important aspects, which are also the most visible and those on which everyone has a strong opinion: concrete syntactic properties. People might pretend otherwise (“let’s not get bogged down on syntax, this is just one possible form”) but syntax is what the discussions will get bogged down to — keywords or symbols, this order or that order of operands, one instruction with several variants vs. several instructions… — at the expense of discussing the fundamental issues of functionality.
Worse yet, even if a language will be part of the solution it is usually just one facet to the solution.As was already explained in detail in [1], any useful functionality set will naturally be useful through several interfaces: a textual notation with concrete syntax may be one of them, but other possible ones include an API (Abstract Program Interface) for use from other software elements, a Graphical User Interface, a web user interface, yet another for web services (typically WSDL or some other XML or JSON format).
In such cases, starting with a concrete textual language is pretty silly, since it cannot yield the others directly (it would have to be parsed and further analyzed, which does not make sense). Of all the kinds of interface listed, the most fundamental one is the API: it describes the raw functionality, excluding any choice of syntax but including, thanks to contracts, elements of semantics.

Conclusión:

One of the key rules for successful software construction — as for many other ventures of course, especially in science and technology — is to distinguish the essential from the auxiliary, and consequently to devote proper attention to the essential issues while avoiding disputations of auxiliary issues. To define functionality, API is essential; language is auxiliary.
So when should you design a language? Never. Well, hardly ever.

 Si computaramos el tiempo de trabajo para definir el DSL y asegurar que funcione, en tales contextos, la adhesión a la posición de Meyer es segura...

UML en la ICSE 2013

Anteúltimo día de ICSE 2013 (International Conference on Software Engineering) , que muestra un gran número de trabajos de interés y participantes. A esta hora, destaco el que Timothy Lethbridge comenta, aunque por razones diversas: la presentación de Marian Petre "UML in practice", que resume su investigación sobre una muestra de desarrolladores de software, respecto a su uso o no de UML. En el resúmen de Timothy

She conducted an excellent interview-based study of 50 software developers in a wide variety of industries and geographical locations. Her key question was, "Do you use UML".

She found that only 15 out of 50 use it in some way, and none use it wholeheartedly.

A total of 11 use it selectively, adapting it as necessary depending on the audience. Of this group use of diagram types was: Class diagrams: 7, sequence diagrams: 6, activity diagrams: 6, state diagrams: 2 and use case diagrams: 1.

Only 3 used it for code generation; these were generally in the context of product lines and embedded software. Such users, however, tended not to use it for early phases of design, only for generation.

One used it in what she called 'retrofit' mode, i.e. "Not unless the client demands it for some reason".

That leaves the 35 software developers who do not use it (70%). Some reported historical use, and some of these did in fact model using their own notation.

The main complaints were that it is unnecessarily complex, lacks and ability to represent the whole system, and has difficulties when it comes to synchronization of artifacts. There were also comments about certain diagram types, such as state machines being only used as an aid to thinking. In general, diagram types were seen as not working well together.

She did comment on the fact that UML is widely taught in educational programs.

Como Tijs van der Storm comenta, quizá Marian esté martillando los últimos clavos en el ataúd de UML...

También coinciden en sus comentarios James Noble,  Alex Nederlof, y Leif Singer, entre otros. Éste último apunta al uso de UML en educación registrado por Marian, como muchas veces, y en muchos aspectos, corriendo detrás de la situación real.

España y los recursos humanos en informática

Javier Garzas publica hoy algunas reflexiones sobre los profesionales informáticos, que comparto casi en un ciento por ciento, incluyendo sus acotaciones sobre Chile, que hablan de algo que conozco de cerca.
Particularmente los puntos ii y iii

ii. La mayoría (no todas) de las empresas TI en España compiten entre ellas por coste no por calidad, es decir, el proyecto se lo lleva el que menos cobra, y no el que oferta más calidad, o mejores perfiles profesionales (échale un vistazo a este post). A menor precio de venta de proyectos… menos margen para sueldos, y como realmente tener buenos perfiles no es diferenciador (y a los clientes no les preocupa mucho) se contratan ingenieros informáticos baratos o se contratan otros perfiles.
iii. El sector es principalmente de servicios (no de productos). Es decir, se compran horas, o “body shopping” (es decir, cesión de personas al cliente, siendo el cliente quien los gestiona). En cualquier caso no es un modelo de inversiones importantes a medio – largo plazo, no es un modelo en el que se quiera crear el mejor software para en un futuro venderlo y obtener rentabilidad. Es un modelo en el que se quieren cubrir necesidades a corto plazo. Y en este modelo no se quiere el mejor desarrollo, y para ello los mejores profesionales, si no terminar el trabajo cuanto antes.

Ambas razones concurren a un mismo problema: falta de visión estratégica en la dirigencia empresaria en primer lugar (descontando las excepciones), y en la dirigencia política también. Así como en una nación invertir en aquello que crea, innova, multiplica, mejora, es vital para sostener a las futuras generaciones, así sucede para las empresas: una empresa que no invierte en mejorar sus procesos, anticiparse en la visión de sus actividades futuras, o crear nuevas alternativas, es una empresa que se estanca y es superada por su competencia, interna o externa. Este es un problema acentuado en el marco de crisis que vive España hoy, pero que ya sucedía antes: este modelo que observa y critica Javier no es de hoy, sino que también se veía en mejores épocas. Este es un modelo que debe cambiar.
Si disiento en algo de lo que Javier afirma, es en el acento en la regulación (iv. No existe ninguna regulación, es decir, que aún siendo críticios ciertos sistemas informáticos, cualquier profesión puede trabajar en ellos). Este es un punto al que le ha dedicado más de una entrada, y es uno que suelo escuchar entre los profesionales españoles. La regulación sólo sirve para detener la innovación. Poner en manos de un comité regulador la actividad profesional es todo lo contrario de crecer. Los gremios y hermandades se acabaron como solución en la tardía edad media.

Buena presentación sobre MDE

Jordi Cabot publica hoy en Slideshare una muy interesante presentación sobre MDE/MDD, que, si bien hace una introducción general al tema, le dedica lo fundamental a las líneas de investigación y a los puntos problemáticos para lo que define como versión 2.0 de MDE. Dentro de las líneas de trabajo presente y futuro dos aspectos que veo particularmente interesantes son la actividad relacionada con  ingeniería reversa dirigida por modelos (mención especial de MoDisco), y el  manejo de muy grandes modelos, que parece ser un asunto de difícil solución en el marco de las premisas actuales de MDE/MDD.
La presentación es suficientemente detallada y amplia como para que pueda despertar la inquietud de aquellos que todavía dudan del valor de MDD/MDE, y más aún para quienes ya están embarcados en alguna forma de desarrollo basado en modelos. El camino es ancho y abierto...
No lo voy a reproducir: cualquiera puede ver la presentación en Slideshare.

¿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.

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...

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.

...Y para completar, ThoughtWorks habla de tendencias

Publicado por InfoQ, ThougthWorks, la empresa con la que colabora Martin Fowler, publica una evaluación de las tendencias en tecnología en cuatro áreas: técnicas, herramientas, lenguajes, y plataformas. Asigna una prioridad a cada uno de los ítems destacados en este cuadro: Adoptar (rojo), probar (amarillo), investigar (verde), postergar/esperar (azul).
Seguramente se puede disentir en algún ítem, pero en general la tendencia es claramente orientada hacia la agilidad, el desarrollo distribuído, la operación de lenguajes a un nivel más abstracto (DSLs) y el predominio de la arquitectura basada en la web.
La noticia en InfoQ aquí, y el informe, aquí.

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.

Johan den Haan acerca de las virtudes de desarrollo basado en modelos (MDD)

Quisiera destacar algo que ya otros hicieron antes, pero no en castellano: las quince razones que Johan den Haan destaca en defensa del desarrollo basado en modelos. Lo haré muy brevemente, remitiendo a su artículo en inglés, pero en pocos días hablaremos un poco más de la crítica a MDD que se desarrolló en LinkedIn, que es su visión inversa. Tan pronto haya tiempo...
Las quince razones de Johan, simplemente enumeradas:
1. MDD es más rápido
2. MDD ofrece un mejor costo (cost-effectiveness)
3. MDD conduce a una mayor calidad
4. MDD es menos propenso a errores
5. MDD conduce a validaciones más claras
6. MDD produce softwaqre menos afectado por cambios de personal
7. MDD potencia los expertos de un dominio
8. MDD permite a los programadores avanzados a enfocarse en los problemas más árduos
9. MDD tiende un puente entre el enfoque de negocios y el tecnológico
10. MDD permite que el software sea menos sensible a los cambios de requerimientos
11. MDD permite que el software sea menos sensible a los cambios de tecnología
12. MDD realmente fuerza el cumplimento de una arquitectura
13. MDD captura conocimiento del dominio
14. MDD produce documentación actualizada del modelo
15. MDD permite enfocarse en problemas de negocios en lugar de hacerlo en la tecnología

Adhiero cien por cien a ellas. Remito a su artículo para su explicación ampliada; y en unos días, volveremos y daremos una vuelta de tuerca a partir de las críticas comentadas.

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.

Un reclamo por la simplicidad

En los últimos días, poco más de una semana, varias notas convergen a un problema que -a guiarnos por estos comentarios- parece que van alcanzando un tope: la creciente complejidad que resulta del diseño del software, al menos siguiendo la línea predominante publicada (No digo el promedio común de la industria, que sospecho que ha de ser mucho más humilde y próximo al Duct Tape Programmer de Joel Spolsky)
El primero en hablar es el mencionado Joel Spolsky, que presenta de ésta manera el problema:

Here is why I like duct tape programmers. Sometimes, you’re on a team, and you’re busy banging out the code, and somebody comes up to your desk, coffee mug in hand, and starts rattling on about how if you use multi-threaded COM apartments, your app will be 34% sparklier, and it’s not even that hard, because he’s written a bunch of templates, and all you have to do is multiply-inherit from 17 of his templates, each taking an average of 4 arguments, and you barely even have to write the body of the function. It’s just a gigantic list of multiple-inheritance from different classes and hey, presto, multi-apartment threaded COM. And your eyes are swimming, and you have no friggin’ idea what this frigtard is talking about, but he just won’t go away, and even if he does go away, he’s just going back into his office to write more of his clever classes constructed entirely from multiple inheritance from templates, without a single implementation body at all, and it’s going to crash like crazy and you’re going to get paged at night to come in and try to figure it out because he’ll be at some goddamn “Design Patterns” meetup.

And the duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.”

Pocos días después, Rodrigo Corral, en su blog, toma el problema desde el punto de vista de la complejidad desbordada, invirtiendo una frase que Microsoft popularizara ( ‘hasta donde quieres llegar hoy?’), y convirtiéndola en una expresión de cansancio (¿Hasta donde podemos llegar?):

Un anuncio de Microsoft decia: ‘hasta donde quieres llegar hoy’ o algo así, pero la pregunta es más bien ¿hasta donde puede llegar la ingeniería del software?. Comenta Gustavo, vecino de blog y uno de los grandes de Sharepoint (y no solo de Sharepoint) que cada vez la complejidad de los proyectos de Sharepoint es mayor, tanto como para que en muchas ocasiones lo mejor sea esconder la cabeza como un avestruz. Yo lo se bien, pase de conocer a fondo la versión 2003 a caer en la sima de la transición a 2007. Hace tiempo que deje de ser un experto en Sharepoint, si es que alguna vez lo fui del todo, el salto a la versión 2007 me supero, demasiada complejidad para un humano mortal.

En mi opinión lo que Gustavo comenta no solo está ocurriendo en Sharepoint. Es un problema generalizado, cada vez más voces importantes del mundo de la ingeniería de software se preguntan si no hemos alcanzado un punto de singularidad en el que la complejidad de los problemas a resolver se ha incrementado más allá de lo manejable.

[...]Los sistemas son cada vez más complejos, exponencialmente más complejos, pero las herramientas han cambiado solo sutilmente. Ya nos sabemos eso de KISS, si, pero no es suficiente. En esencia, desde que Grace Murray, almirante de la marina estadounidense y probablemente la mujer más influyente en la historia de la ingeniería de software, invento el compilador, no se ha producido un cambio cualitativo importante en la forma en que se hace software. Codificar, compilar, depurar. Solo se han añadido billones de horas hombre al desarrollo de software. Fuerza bruta. El problema es hasta donde escala esta aproximación... cada vez parece más que hemos tocado techo. Hay quien incluso ha puesto nombre a este problema: el dilema de la divergencia del software. Ahí es nada…

[...]Yo personalmente soy pesimista. Todos los intentos de atajar la complejidad que hemos realizado han sido en vano. Los patrones parecían prometedores, pero aunque útiles no han supuesto una revolución. Las herramientas 4GL se postularon como una especie de bálsamo de Saxafrax, que se quedo en nada ¿alguien usa 4GL?. Las herramientas de modelado… en fin… esperemos a Oslo, pero mucho me temo que tampoco será mágico… y necesitamos mucha magia. Las herramientas no van a ser la solución al problema. Fijaros, llevo programando desde VB3.0. En la caja de todas la herramientas de programación que he usado desde entonces ponía algo parecido a ‘mejora tu productividad un X%, siendo X > 20’. He conocido VB4, VB5, VS6, VS2001 (productividad con esteroides gracias a .NET), VS2003… hasta VS2010. Si cada versión hubiese mejorado mi productividad lo que su marketing prometía ahora yo sería capaz de programar con la mente.

Finalmente, hace dos días, leo a Charles Young hablando de StreamInsight, de tal forma que representa claramente lo que Rodrigo comenta:

There are a couple of gotchas. First, don’t do what I did while experimenting. I created a QueryTemplate and serialised it to XML. I then tried to deserialise it as a second, identical, QueryTemplate in the same Server instance. I got back an InvalidDefinition error. It seems you can’t have identical QueryTemplates in a single StreamInsight Server instance.

The second thing to note is that the serialised QueryTemplate does not contain fully qualified references to your event types. You still have to define the event types in your application by calling the CreateEventType method. If you plan to store QueryTemplate XML in some custom repository, you will also need to store the fully qualified names of the .NET types your have defined for your events. Of course, you will also need to ensure that these types are available at runtime.

Much the same argument applies to adapters. The QueryTemplate XML does not contain any information on which input and output adapters you want to bind to your query. However, once you realise that your QueryTemplates are serialisable, it is simple to work out how you might store and manage the template in some repository together with event type and adapter information. All this information, taken together, defines the StreamInsight concept of a query. You can write code to extract it from the repository at run-time and run the query.

The current CTP is just a glorified SDK. Will Microsoft provide a repository and tooling in the release version? I have no idea. Given the freedom StreamInsight offers in terms of event definition, and given the fact that the engine can be hosted in custom applications, it is difficult to see how Microsoft could provide a totally generic end-to-end solution that would support externalisation of queries in any and all circumstances. They could provide a repository and API, and leave it to developers to write the code to exploit the repository. However, you would still need to write the LINQ together with code to create QueryTemplates and extract and upload XML to the repository.

...And so on...

En fin, quisiera sin embargo terminar diciendo que quizá lo que ha alcanzado un tope es el modo de encarar la construcción del software. Dada la complejidad, pretender abordarlo a nivel de campo no será materialmente posible. Disintiendo con Rodrigo, éste es el momento de marchar a los 4GL, aquél paradigma sistemáticamente descartado por los enamorados del código, especialmente si es el más novedoso, y elevar el nivel de abstracción. Mucho se ha hablado aquí de ésto, y no es necesario ser redundante.

Proyecto Oslo: ¿en el camino de Vista?

Repentinamente, Douglas Purdy, el 17 de este mes, da un nuevo giro al alcance de Oslo, incluyendo una dimensión de manipulación de datos:

During the 10 months since the last PDC, it has become increasingly clear to us that the modeling platform is aligned in a deep and fundamental way with the data programmability stack (ADO.NET, EF/EDM, Astoria, etc.).

Why?

The fundamental focal point of “Oslo” has always been the notion of (meta)data stored within SQL Server or another database. If you look at the Repository, it has always been “just a SQL Server database” containing application metadata. Likewise, “M” and “Quadrant” having their roots in making this particular database easier to use.

With this in mind, we made a decision to merge the Data Programmability team (EDM, EF, Astoria, XML, ADO.NET, and tools/designers) and the “Oslo” team (“Quadrant”, Repository, “M”) together.

What does this mean for you (.NET developers)? You are going hear more about how “M”/EF/EDM align. How our VS tools relate to “Quadrant”. How this notion of “model-driven software” evolves with the existing .NET FX investments.

Darryl K Taft comenta al día siguiente en EWeek:

Purdy said more on this strategy will be revealed at the upcoming PDC in November. He said developers will learn more about how M, EF and EDM align, how Microsoft's Visual Studio tools relate to Quadrant, and how the notion of model-driven software evolves with Microsoft's .NET Framework investments.This should help to clear up some of the confusion Microsoft caused by shifting the focus of Oslo while keeping the name and the thrust of the project. "Oslo" software modeling technology appears to be something of a chameleon in that it continues to evolve and take on different appearances based on its surroundings. Now Oslo has moved in a new direction, or at least the Oslo team is adapting and merging with Microsoft's Data Programmability team.

[...] Purdy acknowledged the confusion in his post, saying: "The only thing that I feel bad about is that we kept the 'Oslo' name around so long (you will see that change at the next PDC), which has continued to be a confusing point for customers ('I thought Oslo was your new SOA platform.')"

In trying to explain what Oslo is all about, that question has been a recurring theme. So it's good to see Microsoft address this issue. However, Microsoft officials said they had no comment about the future of Oslo beyond what was in Purdy's post.

Francamente, estos trascendidos, idas y vueltas, recuerdan a la larga y confusa historia de Windows Vista, incluyendo el hecho de vender lo que no está, y quizá no se esté seguro de qué es o para qué se utilizará. Realmente parecen algo prematuras las calurosas palabras de bienvenida a las sucesivas presentaciones. Sería bueno tener algo más en firme cuando pareciera que se hablara de un producto que evoluciona a medida que se van descubriendo relaciones.

Quién es Douglas Purdy: De la presentación "A Lap Around Oslo", conducida por Douglas y Vijaye Raji

"Douglas Purdy is a product unit manager at Microsoft working on next-generation languages and tools to broaden the franchise of people building applications. His vision is to “make everyone a programmer” (even if they don’t know it). Previously, Douglas was the group program manager for the Windows Communication Foundation (WCF/Indigo) and Windows Workflow Foundation (WF/WinOE) teams. Douglas has been with Microsoft, on and off, since 1998 where he has worked in consulting, evangelism and engineering."

Leído primero en ZDNet, comentado por Joe McKendrick.

Discutiendo modelos de programación...

El hombre es esclavo de sus palabras...Michael Braude, Ingeniero de Software de Microsoft, critica a quienes se consideran programadores, o desarrolladores, en tanto construyan aplicaciones para la Web. Y una nube de programadores para la web lo refuta, abriendo una discusión sobre el estado de las arquitecturas y paradigmas de construcción de software. Y el cargo a Braude es de estar algo "outdated"...con el corolario extraído por más de una persona, de que el error es extensible a su contratante, Microsoft:

Well the fact that Michael works for Microsoft is a bit disturbing. Perhaps it is linked in with how Microsoft first missed the boat on the importance of the internet.
Pacifika on August 14, 2009 5:47 AM

Jeff Atwood, en The Coding Horror, cuestiona sus argumentos -en realidad, conocí la discusión por su nota- y da vuelta su argumentación, sosteniendo que en realidad las aplicaciones de escritorio ya están muertas.
Así, Atwood toma las palabras de Braude:

The reason most people want to program for the web is that they're not smart enough to do anything else. They don't understand compilers, concurrency, 3D or class inheritance. They haven't got a clue why I'd use an interface or an abstract class. They don't understand: virtual methods, pointers, references, garbage collection, finalizers, pass-by-reference vs. pass-by-value, virtual C++ destructors, or the differences between C# structs and classes. They also know nothing about process. Waterfall? Spiral? Agile? Forget it. They've never seen a requirements document, they've never written a design document, they've never drawn a UML diagram, and they haven't even heard of a sequence diagram.

But they do know a few things: they know how to throw an ASP.NET webpage together, send some (poorly done) SQL down into a database, fill a dataset, and render a grid control. This much they've figured out. And the chances are good it didn't take them long to figure it out.

So forgive me for being smarmy and offensive, but I have no interest in being a 'web guy'. And there are two reasons for this. First, it's not a challenging medium for me. And second, because the vast majority of Internet companies are filled with bad engineers - precisely because you don't need to know complicated things to be a web developer. As far as I'm concerned, the Internet is responsible for a collective dumbing down of our intelligence. You just don't have to be that smart to throw up a webpage.

I really hope everybody's wrong and everything doesn't "move to the web." Because if it does, one day I will either have to reluctantly join this boring movement, or I'll have to find another profession.

Y le contesta con su cuestionamiento del paradigma de las aplicaciones de escritorio:

Let's put aside, for the moment, the absurd argument that web development is not challenging, and that it attracts sub-par software developers. Even if that was true, it's irrelevant.

I hate to have to be the one to break the bad news to Michael, but for an increasingly large percentage of users, the desktop application is already dead. Most desktop applications typical users need have been replaced by web applications for years now. And more are replaced every day, as web browsers evolve to become more robust, more capable, more powerful.

You hope everything doesn't "move to the web"? Wake the hell up! It's already happened!

Uno de los argumentos en favor de las aplicaciones Web de Atwood es su ubicuidad y facilidad de distribucion:

If you want your software to be experienced by as many users as possible, there is absolutely no better route than a web app. The web is the most efficient, most pervasive, most immediate distribution network for software ever created. Any user with an internet connection and a browser, anywhere in the world, is two clicks away from interacting with the software you wrote. The audience and reach of even the crappiest web application is astonishing, and getting larger every day.
[...] As a software developer, I am happiest writing software that gets used. What's the point of all this craftsmanship if your software ends up locked away in a binary executable, which has to be purchased and licensed and shipped and downloaded and installed and maintained and upgraded? With all those old, traditional barriers between programmers and users, it's a wonder the software industry managed to exist at all. But in the brave new world of web applications, those limitations fall away. There are no boundaries. Software can be everywhere.

En fin. Las palabras de Braude se publican en su blog personal; como él dice en su introducción, "The opinions and views expressed on my blog are mine and have nothing to do with my employer. I am just one of 90,000 employees, and plenty of them would disagree with what I say here". Sin embargo, existe más de una coincidencia entre su punto de vista, y la puja global de Microsoft con Google. ¿No es así?

Workshop sobre OCL

A través de la lista de noticias del grupo MDD-MDA, Jordi Cabot informa sobre la próxima conferencia de ACM/IEEE sobre Lenguajes y Sistemas basados en Modelos (ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems). Particularmente, el anuncio está orientado a difundir y promover aportes al workshop sobre OCL. Este es un soporte básico del desarrollo de modelos, al menos en términos de OMG. La presentación del workshop describe su importancia y dá una idea de su estado actual:

In recent years, MDA and associated MDE methodologies, approaches and languages (like QVT) emphasized the role that OCL has to play in MDE development. Moreover, the modeling community is continuously pushing forward the OCL, far beyond its initial requirements as a precise modeling language complementing UML specifications. Now, OCL is used in quite different applications domains (e.g., domain-specific languages, web semantics) and for various purposes (e.g., model verification and validation, code generation, test-driven development, transformations).

This workshop will focus on the challenges of using OCL on these new domains and how the language needs to evolve to be successfully applied on them. In particular, we are interested in discussing

• alternative notations/representations for OCL that simplify its application,
• new textual/graphical languages that can complement/replace OCL,
• new ways of writing OCL expressions (e.g., patterns, templates and libraries),
• sharing OCL expressions and OCL know-how,
• new domain-dependent evaluation and optimization strategies,
• mappings from OCL to other languages and formalisms (Java, SQL, Alloy, Maude, constraint programming, ...)
• and, of course, the tools that will make all of this possible.

Dos sitios relacionados son de interés:
Metamodel, que publicará los trabajos, y desarrolla actividades vinculadas a MDE, y MOdeling LAnguages, enfocado en MDE/MDA.

Críticas a MDD desde dentro: Rigidez del código, parte II

Tratando de completar las ideas que el primer punto de Johan sugiere, quisiera volver sobre el carácter abstracto de MDD (The goal of MDD is to ‘program' on a higher level of abstraction. This means that you have to specify less and generate more. However, this also means that you can't change every little detail you want).
Muchas de las objeciones atribuidas primero a MDA, pero luego extensibles a MDD (la visión ampliada y variada del diseño basado en modelos), están aquí. El primer acusado es UML, el estándar definido por OMG primero como herramienta de modelado, y luego como soporte para expresar modelos traducibles a código. ¿Es suficiente UML para expresar de manera abstracta toda la lógica de un sistema? ¿Es posible bajar en el nivel de detalle de un sistema recurriendo sólo a las herramientas propias de UML (vistas de diagramas y OCL)? Estas objeciones provienen especialmente de quienes usan o discuten MDA; sin embargo, no escapan a estas preguntas las variadas alternativas de solución ajenas a MDA (Johan describe algunas de estas variantes).
MDD, en sus distintas vertientes, probablemente esté atravesando un período parecido al que atravesara UML en la década de los 90: distintas notaciones se fueron forjando para expresar el diseño orientado a objetos, convergiendo en un esquema consensuado y no propietario, suficientemente potente como para responder a su tarea. El desarrollo de aplicaciones basado en modelos abstractos y generables, capaces de aplicarse a distintas plataformas y a distintas arquitecturas, mejorará sus herramientas y logrará mejores resultados. ¿El esquema de extensiones de Eclipse podría ser una respuesta a la apuntada "falta de flexibilidad"? ¿Alguna variante de DSLs aplicados en el espacio hoy llamado "rígido" podría aumentar la granularidad de los sistemas?
En el caso de Plex (mi herramienta de trabajo, para cualquiera que lo desconozca), este espacio está cubierto por el concepto de "diagramas de acción": llamémoslo un script abstracto, capaz de moverse en un meta nivel materializable en distintas encarnaciones, fuertemente restringido por los objetos a los que sirve (no es posible referirse a ningún objeto que no esté definido en el modelo, ni violar los tipos que manipula), que puede sin embargo ser detallado y minucioso. ¿Es una solución definitiva? No, porque globalmente podría llegar a expresar en un conjunto de diagramas algo contradictorio con el comportamiento esperado del modelo. No es sustituíble el trabajo del diseñador para expresar su modelo; un mal diseño también puede ser plasmado en un modelo escrito con UML.
En fin, digamos que el punto 1 de los ocho enumerados por Johan den Haan, pone el acento en un problema en discusión, que está en el laboratorio. Y que probablemente se refinará y quizá incluso desaparezca. Sin duda, en primer lugar, su objeción a la calidad de la interface gráfica.
En los próximos días seguiremos con otros puntos...

MoDisco: Ingeniería reversa guiada por modelos

Jean Bézivin, a quien se ha recordado aquí más de una vez, promueve y participa en un proyecto de especial interés: MoDisco ( abreviando Model Discovery), que se propone la extracción de modelos partiendo del análisis de sistemas antiguos (legacy systems). A mi juicio, este es un movimiento de importancia en el camino de avanzar hacia aplicaciones basadas en modelos: Si se examina la realidad del uso de sistemas informáticos, el panorama deja una gran heterogeneidad, un gran volúmen de sistemas obsoletos, y una débil penetración de estos conceptos, que dominan las actividades de grupos académicos y conferencias, pero que representan un porcentaje bajo del modo en que se construyen las aplicaciones en el mundo real. Si tomamos las búsquedas laborales, los ránkings de uso de lenguajes, lo que se entrevé de la vida diaria, encontramos un extenso uso de lenguajes de tercera generación, comenzando por COBOL (especialmente en España), RPG, Visual Basic, Java, C, C++...Una coexistencia de viejas aplicaciones que no se tocan porque funcionan, con modernos intentos cubriendo aspectos parciales, o viceversa, modernos paquetes preplaneados que integran antiguos desarrollos.
Por tanto, una herramienta que partiendo de lo que existe, permite crear un marco de abstracción adecuado para encauzar la construcción de software, abre posibilidades de facilitar la ampliación del uso de mejores herramientas, acortando el camino entre el desarrollo basado en modelos y las aplicaciones existentes. Como siempre se ha destacado aquí, manejar la construcción de las aplicaciones desde la abstracción de un modelo es la manera de superar esta compleja coexistencia que inevitablemente se dará en la vida real.
En fin, el objetivo de MODISCO es facilitar un puente hacia este terreno.
De la presentación del proyecto:

MoDisco (for Model Discovery) is an Eclipse-GMT project for model-driven reverse engineering. The objective is to allow practical extractions of models from legacy systems. Because of the widely different nature and technological heterogeneity of legacy systems, there are several different ways to extract models from such systems. MoDisco proposes a generic and extensible metamodel-driven approach to model discovery. A basic framework and a set of guidelines are provided to the Eclipse contributors to bring their own solutions to discover models in various kinds of legacy.

Sobre la importancia de su enfoque para hacer ingeniería reversa de antiguos sistemas, dice su presentación:

What are the benefits of the MoDisco approach compared to already existing reverse engineering tools?

First, MoDisco proposes a unified approach to model-driven reverse engineering and a metamodel driven methodology. This way, we are able to work in the modeling world, coming from a heterogeneous world to a homogeneous one. The target model engineering space already proved its adaptability and scalability by several experiments to match requirements for data integration, tools interoperability and platform migration.

Moreover, the well structured modeling world allows easy manipulation of many different concepts in a unified way. For instance, every model can be transformed, weaved, extracted with the same tool set. As those operations are defined upon models’ metamodels, they are reusable for different use cases.

Una característica (propia de Eclipse) es su característica de ser extensible, lo que deja abierta la posibilidad de adecuarlo a diferentes requerimientos a partir de su núcleo.

The MoDisco framework is a generic framework that provides a basis for extension. It offers a minimum tool set to allow model discovery. The first component is a base metamodel. It is based on the Knowledge Discovery Metamodel (KDM) from the OMG. Actually, it is a minimal subset of KDM allowing end users to define (by extension) some KDM compliant metamodels. The framework offers facilities to manipulate models which metamodels are extensions of the base metamodel.

Sobre los soportes en que se basa MODISCO:

Due to the highly diversified nature of the considered legacy, MoDisco is a collaborative project involving several organizations. Each of them will bring its own expertise in a given area. MoDisco will use as often as possible the solutions elaborated by the OMG ADM (Architecture Driven Modernization) Task Force.
(...) As a GMT project, MoDisco will make good use of other GMT projects or solutions available in the Eclipse Modeling Project (EMF, M2M, GMF, TMF, etc), and more generally of any plugin available in the Eclipse environment.

Puede consultarse su documentación en el mismo sitio.

Nota: Este artículo fue adelantado parcialmente ayer. Esta es su versión "definitiva"
Nota 2: La imágen pertenece al sitio, y es reproducida en la hoja de información rápida y en el papel de presentación.