Harto de videos y ppts...

Diariamente recibo mucho material de tecnologías que me interesan, novedades, recomendaciones, y una buena cantidad de lo arribado me atrae. Pero cuando trato de analizar estos materiales, usualmente encuentro que refieren, en un 70/80 por ciento de los casos, a videos y/o presentaciones a través de secuencias de diapositivas: información rápida, a veces elaborada al galope, de la que se puede sacar poco provecho. ¿Soy una excepción que no encuentra el valor didáctico de presentar un problema en una secuencia de imágenes, en muchas ocasiones en un lenguaje distinto al tuyo? ¿O se trata de que el material no prentende ser didáctico, y mucho menos motivador para pensar, sino simplemente difusor, para generar una corriente de adhesiones...que continúen viendo videos? No niego que pueda ser un auxiliar importante cuando quieras analizar un proceso que vas aprendiendo, al modo en que un profesor o instructor ayudaría a despejar dudas sobre aspectos prácticos de algo. Pero cuando el ochenta por ciento del material de conocimiento es visual, sin duda perderás lo importante. Leer un papel, leer, permite ir adelante y atrás, desmenuzar, anotar, escribir. Ver un video sumerge en la corriente del discurso, suponiendo que el presentador mantenga el interés, y no nos debamos perder en interpretaciones de jerga extranjera ¿mirarías tres veces una presentación para entender un párrafo? ¿qué haces con una presentación de diapositivas que ni siquiera tiene el respaldo del orador explicando? ¿qué haces con las "divertidas" imagenes presentando paradojas del problema que vas a tratar, o con las "preciosas" transiciones de imágenes usuales en una presentación? ¿De qué le sirven a un orador las trasiciones divertidas mientras presenta un problema? ¿Cuál es su foco? Recuerdo que algún colaborador de Steve Jobs echaba de las reuniones a quien presentara un problema con un power point. Creo que lo comparto...la única manera en que me interesa una presentación de cualquiera de estos tipos es cuando se trata de una mínima lista de puntos a ser discutidos. Y si publico uno de estos, debería ir acompañado del texto que glosa. Quizá la ventaja del video o el ppt sea que se pueden fabricar como chorizos...Quizá a otro le sirvan, pero a mí me han simplificado la vida...de cada treinta, creo que miro uno.

IBM como parte de la historia tecnológica

Un artículo aquí que suele ser visitado es el que habla sobre la historia de los servidores de IBM. Lamentablemente, el enlace que abre el artículo hace mucho tiempo que dejó de apuntar a algo, viejo problema de cualquier artículo apoyado en la web...A raíz de éste y otros casos similares, hace tiempo que reemplazo los enlaces por un extracto del tema de que se trate. No pierdo la esperanza de recuperar el viejo artículo, pero algo se puede hacer: gracias a The wayback machine, se puede recuperar un corte de la página al 5 de enero de 2007, que refleja en general el contenido de aquella página. Esta referencia se incluye ahora en mi nota de 2006. Dada la volatilidad del material escrito para Internet, The Internet Machine cumple un servicio irreemplazable.
Pero volviendo a IBM y su influencia en el desarrollo tecnológico del siglo XX: a raíz de su centenario, la empresa ha desarrollado mucha documentación que supongo que será más persistente. El conjunto más importante de documentos, es el que enumera cien aportes de IBM a la tecnología. Lamentablemente, por falta de tiempo dejé pasar el mejor momento para reproducir excelentes materiales difundidos durante el centenario. No obstante, este resumen y otros posteriores se proponen remediarlo. Y respecto a IBM, la observación más destacada acerca de su centenario, no es tanto acerca de su capacidad de crecer y mantenerse en la primera línea de la investigación tecnológica, sino la pregunta sobre su futuro: hace ya algunos años IBM ha producido un giro radical en su visión de los negocios, que por ahora da buenos dividendos, pero pone en cuestión su liderazgo tecnológico, y su esfuerzo en el desarrollo de la investigación. La pregunta es ¿tendrá un segundo siglo de liderazgo?

Volviendo a los papeles del centenario: puestos en desorden, simplemente por preferencias y a medida que los voy encontrando, el primero para reproducir es el dedicado a Codd y las bases de datos relacionales:

In 1970, Edgar F. Codd, an Oxford-educated mathematician working at the IBM San Jose Research Lab, published a paper showing how information stored in large databases could be accessed without knowing how the information was structured or where it resided in the database.

Until then, retrieving information required relatively sophisticated computer knowledge, or even the services of specialists who knew how to write programs to fetch specific information—a time-consuming and expensive task.
Databases that were used to retrieve the same information over and over, and in a predictable way—such as a bill of materials for manufacturing—were well established at the time. What Codd did was open the door to a new world of data independence. Users wouldn’t have to be specialists, nor would they need to know where the information was or how the computer retrieved it. They could now concentrate more on their businesses and less on their computers.
Codd called his paper, “A Relational Model of Data for Large Shared Data Banks.” Computer scientists called it a “revolutionary idea.”
Today, the ease and flexibility of relational databases have made them the predominant choice for financial records, manufacturing and logistical information, and personnel data. Most routine data transactions—accessing bank accounts, using credit cards, trading stocks, making travel reservations, buying things online—all use structures based on relational database theory.

Codd’s idea spawned a new family of products for IBM, centered on the IBM ^® DB2 ^® database management system, as well as the industry-standard computer language for working with relational databases, called SQL.
According to the New York Times obituary for Codd, “… before Dr. Codd’s work found its way into commercial products, electronic databases were ‘completely ad hoc and higgledy-piggledy,’ said Chris Date, a relational data expert who worked on DB2 at IBM before becoming a business partner of Dr. Codd’s.”
Like many revolutionary ideas, the relational database didn’t come about easily.
By the 1960s, the vast amount of data stored in the world’s new mainframe computers—many of them IBM System/360 machines—had become a problem. Mainframe computations were expensive, often costing hundreds of US dollars per minute. A significant part of that cost was the complexity surrounding database management.
Codd, who had added a doctorate in computer science to his math background when he came to the United States from his native England, set out to solve this problem. He started with an elegantly simple premise: He wanted to be able to ask the computer for information, and then let the computer figure out where and how the information is stored and how to retrieve it.
IBM’s Don Chamberlin said that Codd’s “basic idea was that relationships between data items should be based on the item’s values, and not on separately specified linking or nesting. This notion greatly simplified the specification of queries and allowed unprecedented flexibility to exploit existing data sets in new ways.”
In his seminal paper, Codd wrote that he used the term relation in the mathematical sense of set theory, as in the relation between groups of sets. In plain terms, his relational database solution provided a level of data independence that allowed users to access information without having to master details of the physical structure of a database.
As exciting as the theory was to the technical community, it was still a theory. It needed to be thoroughly tested to see if and how it worked. For several years, IBM elected to continue promoting its established hierarchical database system, IBM IMS (Information Management System). A hierarchical system uses a tree-like structure for the data tables. While IMS can be faster than DB2 for common tasks, it may require more programming effort to design and maintain it for non-primary duties. Relational databases have proven superior in cases where the requests change frequently or require a variety of viewpoint “angles.”
IBM, Rockwell and Caterpillar developed IMS in 1966 to help track the millions of parts and materials used in NASA’s Apollo Space Program. It continues to be IBM’s premier hierarchical database management system.
In 1973, the San Jose Research Laboratory—now Almaden Research Center—began a program called System R (R for relational) to prove the relational theory with what it called “an industrial-strength implementation.” The project produced an extraordinary output of inventions that became the foundation for IBM’s success with relational databases.
Don Chamberlin and Ray Boyce invented SQL, for Structured Query Language, today the most widely used computer language for querying relational databases. Patricia Selinger developed a cost-based optimizer, which makes working with relational databases more cost-effective and efficient. And Raymond Lorie invented a compiler that saves database query plans for future use.
In 1983, IBM introduced the DB2 family of relational databases, so named because it was IBM’s second family of database management software. Today, DB2 databases handle billions of transactions every day. It is one of IBM’s most successful software products. According to Arvind Krishna, general manager of IBM Information Management, DB2 continues to be a leader in innovative relational database software.
Dr. Codd, known as “Ted” to his colleagues, was honored as an IBM Fellow in 1976, and in 1981, the Association for Computing Machinery gave him the Turing Award for contributions of major importance to the field of computing. The Turing is generally recognized as the Nobel Prize of computing.

Selected team members who contributed to this Icon of Progress:

• Ray Boyce Co-developer of SQL (Structured Query Language)

• Edgar “Ted” Codd Mathematician, IBM Fellow

• Donald Chamberlin Co-developer of SQL

• Christopher J. Date Longtime collaborator of Ted Codd

• Patricia G. Selinger Founding manager of the Database Technology Institute at IBM Almaden Research Center

Los enlaces del artículo reproducido son míos.

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.