sábado, diciembre 30, 2006

El método Toyota

El 26 de diciembre, InfoQ publicó un brevísimo artículo de Deborah Hartmann sobre Toyota en Estados Unidos y los métodos "livianos", o "ágiles" (Lean manufacturing) de la empresa, escrito a propósito del que escribiera Charles Fishman para Fast Company en su número de diciembre. El comentario de Fishman sobre el funcionamiento de la planta de Toyota en Kentucky da para extraer ideas generalizables o aplicables en muchos otros ámbitos, entre los cuales la construcción de software es uno posible, pero no el único. Una lectura del artículo puede convocar ideas de cómo extenderlo a el negocio que le parezca, incluso uno social...
Los principios comentados por Fishman recuerdan la herencia de los principios de TQM (Total Quality Management) en los métodos de Toyota, que quizá sea lo que le falta a los intentos de emular a la empresa por su competencia americana:
It's the story of Toyota's genius: an insatiable competitiveness that would seem un-American were it not for all the Americans making it happen. Toyota's competitiveness is quiet, internal, self-critical. It is rooted in an institutional obsession with improvement that Toyota manages to instill in each one of its workers, a pervasive lack of complacency with whatever was accomplished yesterday.
(...) The process is, in fact, paramount--so important that "Toyota also has a process for teaching you how to improve the process," says Steven J. Spear, a senior lecturer at MIT who has studied Toyota for more than a decade. The work is really threefold: making cars, making cars better, and teaching everyone how to make cars better. At its Olympian best, Toyota adds one more level: It is always looking to improve the process by which it improves all the other processes.
(...) Lean manufacturing and continuous improvement have been around for more than a quarter-century. But the incessant, almost mindless repetition of those phrases camouflages the real power behind the ideas. Continuous improvement is tectonic. By constantly questioning how you do things, by constantly tweaking, you don't outflank your competition next quarter. You outflank them next decade.
(...) What happens every day at Georgetown, and throughout Toyota, is teachable and learnable. But it's not a set of goals, because goals mean there's a finish line, and there is no finish line. It's not something you can implement, because it's not a checklist of improvements. It's a way of looking at the world. You simply can't lose interest in it, shrug, and give up--any more than you can lose interest in your own future.
Fisher compara la empresa con su competencia americana, que cede día a día posiciones en el mercado de automóviles:
Lots of companies have tried to learn and use the methods that Toyota has refined into a routine, a science, a way of being and thinking. Not least among those are … GM, Ford, and Chrysler (NYSE:DCX). For more than 20 years, in fact, Toyota and GM have operated a car factory together in California--the NUMMI project--that has allowed GM to study Toyota's methods up close.
And the Big Three have each gotten better at making cars: In the past decade, GM and Chrysler have cut by one-third the hours they need to assemble a car. But they all still trail Toyota. No one knows that better than GM. "We've made a whole lot of progress," says Dan Flores, a spokesman for GM's North American manufacturing operations--much of it by learning directly from Toyota. "Transforming a company the size of GM is a daunting task. The culture of the plants doesn't change overnight. But there has been a cultural change in the company--and that change continues."
La diferencia de enfoque, un largo camino por recorrer:

Typically, though, the Big Three take an all-too-American approach to the idea of improvement. It's episodic, it's goal-oriented, it's something special--it's a pale imitation of the approach at Georgetown. "If you go to the Big Three, you'd find improvement projects just like you'd find at Georgetown," says Jeffrey Liker, a professor of engineering at the University of Michigan and author of The Toyota Way, a classic exploration of Toyota's methods. "But they would be led by some kind of engineering group, or a Six Sigma black belt, or a lean-manufacturing guru of some kind.
"They might even do as good a job as they did at Georgetown. But here's the thing. Then they'd turn that project into a PowerPoint. They'd present it at every place in the whole company. They'd say, 'Look what we did!' In a year, that happens a couple of times in a whole plant for the Big Three. And it would get all kinds of publicity in the company.
"Toyota," Liker says, "is doing it in every single department, every single day. They're doing it on their own"--no black belts--"and they're doing it regularly, not just once."
So you can buy the books, you can hire the consultants, you can implement the program, you can preach business transformation--and you can eventually run out of energy, lose enthusiasm, be puzzled over why the program failed to catch fire and transform your business, put the fat binders on a conference-room shelf, and go back to business as usual.

Existen observaciones americanas sobre el método de Toyota, que también deben ser vistas, por ejemplo, las recogidas en Gemba.

viernes, diciembre 29, 2006

Microsoft patenta ideas relacionadas con RSS

Microsoft patentó en Estados Unidos conceptos relacionados con RSS (Really Simple Syndication). Esto no es la primera vez que sucede, y no parece abarcar la definción del formato en sí. Pero es para tener en cuenta. La presentación en la oficina de patentes:
Finding and consuming web subscriptions in a web browser
A content syndication platform, such as a web content syndication platform, manages, organizes and makes available for consumption content that is acquired from the Internet. In at least some embodiments, the platform can acquire and organize web content, and make such content available for consumption by many different types of applications. These applications may or may not necessarily understand the particular syndication format. An application program interface (API) exposes an object model which allows applications and users to easily accomplish many different tasks such as creating, reading, updating, deleting feeds and the like. Further, in at least some embodiments, a user can subscribe to a particular web feed, be provided with a user interface that contains distinct indicia to identify new feeds, and can efficiently consume or read RSS feeds using both an RSS reader and a web browser.
(Esta patente no reclama a RSS, sino que se apoya en el formato)
Content syndication platform
A content syndication platform, such as a web content syndication platform, manages, organizes and makes available for consumption content that is acquired from the Internet. In at least some embodiments, the platform can acquire and organize web content, and make such content available for consumption by many different types of applications. These applications may or may not necessarily understand the particular syndication format. An application program interface (API) exposes an object model which allows applications and users to easily accomplish many different tasks such as creating, reading, updating, deleting feeds and the like.
(Esta patente, tampoco parece reclamar al protocolo).

Publicado en Dr.Dobbs, que menciona los comentarios de Dave Winer y Nick Bradbury.

martes, diciembre 26, 2006

Indice de adopción de TI en América Latina

La consultora española Everis (ex DMR) y la escuela de negocios IESE elaboraron un estudio sobre el índice de adopción en América Latina:
La región registró 4,33 puntos de un total de 10, un aumento de 1,8% frente al 3T05, lo que representa el puntaje más alto anotado desde que everis comenzó el Information Society Indicator (ISI) en el segundo trimestre del 2005. El estudio se realiza en conjunto con la escuela española de negocios IESE y mide la adopción de TI en forma trimestral en la región y entrega información detallada sobre Chile, Argentina, Brasil y México.
Chile lideró el índice con 5,59 puntos, seguido por Argentina (4,52), México (4,31) y Brasil (3,93). A pesar de su lugar en el ranking, el índice de Chile disminuyó un 0,2% respecto del 3T05, mientras que Argentina logró el mayor crecimiento con un incremento de 5,5% año con año.
El índice ISI mide indicadores de TIC tales como la cantidad de teléfonos celulares en servicio, la cantidad de computadores y usuarios de internet por cada 1.000 habitantes, además del ambiente general, incluyendo el gasto en TI como proporción del PIB y el uso de la electricidad por persona.
El gerente general de everis, Juan Francisco Yáñez, señaló a la prensa que en términos de sociedad de información, Chile también se ubica en primer lugar en la región con 5,76 puntos, destacándose con 8,17 puntos en el índice que mide las entidades públicas locales. Sin embargo, el índice general ha disminuido un 0,2%, principalmente a raíz de que el país bajó del lugar número 11 al 14 en el índice de libertad económica, agregó.
El estudio proyecta que la adopción de TI en Latinoamérica debiera crecer un 1,1% en el 4T06 y caer un 0,6% en el 1T07 a 4,29 a fines de marzo. La cantidad de usuarios móviles en la región podría llegar a 554 por cada 1.000 habitantes, un repunte de 12,2% comparado con marzo del 2006, con un crecimiento aún más rápido en la cantidad de computadores y usuarios de internet.
La empresa cree que Chile y Argentina serán los únicos países en el grupo que presentarán aumentos en sus índices ISI en los próximos dos trimestres.
(Tomado de Proexport Colombia , 11 de diciembre 2006)
El informe se puede consultar en el sitio del IESE.

lunes, diciembre 25, 2006

Participación latinoamericana en el comercio del software

A propósito de un artículo de Horacio Bruera para La Nación de Argentina, se pueden medir los intentos y logros de los países latinoamericanos por tomar una porción del mercado mundial de Tecnología Informática. La nota de Bruera destaca a Chile, ya que un aspecto importante de las estrategias chilenas de crecimiento, es el seguimiento institucional de su comercio exterior, convirtiéndolo en generador fundamental de producto nacional. Si bien el principal ingreso de Chile es un commodity -el cobre-, el esfuerzo puesto en cada área es destacable, y sirve para pensar otros modelos. Bruera destaca la calificación arancelaria de los servicios de software, y el impacto de esta medida en la actividad de las empresas interesadas:
(...) el sistema arancelario chileno ofrece una novedad que marca su singularidad en América latina y en muchos países del mundo: el suministro transfronterizo de software y servicios informáticos es considerado un servicio exportable y, por lo tanto, debe estar contemplado bajo la partida 00.25 (incluida por primera vez el 17 de enero de 2004 en la sección "0" del Arancel Aduanero chileno, correspondiente a Tratamientos Arancelarios Especiales).
La Dirección Nacional de Aduanas estableció, además, que "los exportadores de servicios deberán dar pleno cumplimiento de las normas establecidas en la resolución 3635 del 20 de agosto de 2004, cualquiera que sea el modo de envío de los servicios al exterior". Esto implica condicionar la obtención de beneficios fiscales y aduaneros al cumplimiento de una serie de requisitos determinados en dicha resolución
Pero yendo más allá, Bruera menciona un informe de Proargentina, que remite a una visión más general del volúmen de los esfuerzos de diversos países por ganar un sitio en el mercado global. El informe, y otros documentos relacionados que lo mencionan en otros casos (Ecuador, Colombia), ofrece un buen soporte para investigar el tema, tanto en cuanto a los esfuerzos para ganar posiciones en el mundo, como para conocer las características y necesidades de los principales mercados nacionales.
Este informe, fechado en enero de 2005, tiene referencias estadísticas en general limitadas hasta 2003. Esto es importante para los números de Argentina, que continuó creciendo posteriormente (Haré apuntes a esta nota cuando tenga la continuidad de las cifras publicadas).
Un hecho que se destaca del informe es la importancia de Brasil, que debiera recordarse más de lo que se hace, y que recuerdan que el país se perfila como un competidor global.
En cifras, el informe indica un volúmen aproximado de diez mil empresas en la industria del software, con ingresos aproximados de 18.000 millones de dólares (91% de ellas dedicadas al desarrollo de software), de las que el 75% son pequeñas empresas de 50 empleados o menos.
Como en el resto de Latinoamérica, en el lote de las primeras ocho empresas, seis de ellas son extranjeras (medido en facturación), pero las locales representan la mitad en las primeras quince.
El informe menciona el programa SOFTEX (Sociedad para la promoción y excelencia del software), iniciado en 1993, que sostiene líneas de crédito de promoción, coordina polos de desarrollo con la participación de alrededor de mil empresas, y facilita acciones de promoción (incubadoras y desarrollo de emprendedores) en el interior de las universidades orientadas a la informática.
A 2005, las cifras, sin embargo, ponen a Argentina en primer lugar en la exportación de software y servicios vinculados. (180 millones de dólares de Argentina contra cien millones de Brasil). El objetivo estatal brasilero es llevar sus exportaciones a 2000 millones para el año próximo.
Visto en conjunto, el mercado latinoamericano aparece lejos de los principales competidores, aunque el informe muestra el esfuerzo de varios países por mejorar el posicionamiento (Argentina, Brasil, Chile, Uruguay).

domingo, diciembre 17, 2006

Journal of Object Technology

Excelente material: Journal of Object Technology. Participan en su equipo editorial nombres que garantizan un trabajo consistente en OO: Kent Beck, Peter Coad, Ivar Jacobson, Bertrand Meyer, Erich Gamma, James Gosling, o Jean Bézivin, por mencionar a los más destacados.

Journal of Object Technology (JOT) is an on-line peer-reviewed publication, published six times per year by the ETH Swiss Federal Institute of Technology, aimed at intermediate to advanced practitioners, educators and researchers in the field of object technology.

The mission of JOT is to present its readers with timely, well-written, and interesting state-of-the-art papers and special features (columns, book reviews, software reviews) dealing with every aspect of object technology both theoretical and practical. Topics include OOA, OOD, patterns, OODBMS, OO languages, components and case studies. The columns, both guest and regular, are written by recognized specialists and experts in the field.

miércoles, diciembre 13, 2006

The Times: Ranking sin Universidades Latinoamericanas

Infobae comenta la publicación de The Times del ranking de las mejores universidades en el mundo, que elabora por tercer año. En este caso, las universidades iberoamericanas salen algo peor clasificadas que en el mantenido por la Universidad de Jiao Tong, de Shanghai: sólo una latinoamericana entre las cien primeras , la Universidad Autónoma de México (74), y sólo un puñado entre las primeras quinientas. Le siguen, fuera del lote de las primeras doscientas, la Universidad Católica de Chile (228), la Universidad de Buenos Aires (276), la Universidad de Chile (277), la de San Pablo, Brasil (284), la Austral, de Argentina (289), y Monterrey, México, (299). Más allá de las primeras trescientas, la ORT de Uruguay (329), Río de Janeiro (416), de Los Andes, Colombia (418), la Católica de Perú (418), la Católica de Río de Janeiro (441), la Paulista (478), la Torcuato Di Tella, de Argentina (493), y la Diego Ibáñez, de Chile (504). Con mayor presencia , pero rankeadas por detrás de otras muchas europeas, se encuentran las españolas (La primera presente, la Universidad de Barcelona, 190). Es de destacar el aislado esfuerzo de la UNAM, mejorando incluso su posición respecto al año 2005.
Si bien la información ofrecida por Infobae es inexacta en cuanto a la presencia argentina, sin duda es posible suscribir su afirmación de que las universidades argentinas pasan por un (largo) período de decadencia, bien expresado en la anarquía institucional que atraviesa la UBA.
El método del ranking :
La elección de las universidades fue hecha a partir de una evaluación tanto cualitativa como cuantitativa de 3.703 profesores de todas partes del mundo, quienes tuvieron que responder cuestionarios sobre sus áreas específicas.
Se tuvieron en cuenta, a la hora de establecer esta exclusiva lista, la cantidad de publicaciones en revistas especializadas que realizó algún profesor de las universidades votadas, como así también la cantidad de docentes y alumnos extranjeros con que cuentan.(Infobae)
Se tomaron en cuenta cuatro criterios básicos, donde la calidad de la investigación adopta el mayor peso (40%) de la puntuación. Los custionarios fueron respondidos por 3700 integrantes de los establecimientos examinados. Este criterio es particularmente importante, porque es un exámen directo de los integrantes de cada institución: lograr que una universidad tenga un puesto alto en esta escala, implica un prolongado trabajo de capacitación de sus educadores, y una disposición a la investigación que no se resuelve con brillos individuales.
De la explicación de su método de selección, algunos aspectos salientes:
Peer Review: Over 190,000 academics were emailed a request to complete our online survey this year. Over 1600 responded - contributing to our response universe of 3,703 unique responses in the last three years. Previous respondents are given the opportunity to update their response.
Respondents are asked to identify both their subject area of expertise and their regional knowledge. They are then asked to select up to 30 institutions from their region(s) that they consider to be the best in their area(s) of expertise. There are at present approximately 540 institutions in the initial list. Responses are weighted by region to generate a peer review score for each of our principal subject areas which are:
* Arts & Humanities
* Engineering & It
* Life Sciences & BioMedicine
* Natural Sciences
* Social Sciences
The five scores by subject area are compiled into a single overall peer review score with an equal emphasis placed on each of the five areas.
Recruiter Review: Over 375 recruiters responded this year contributing to a total response universe of 738 in the last two years. The recruiter review will operate on the same three year latest response model that the peer review utilises – so we will be operating on a number in excess of 1000 next year. Recruiter names are sourced through QS databases, media partners and partner schools & universities. Responses are weighted by region to reach a final score.
Citations per Faculty: There is a database maintained by Thomson called the Essential Science Indicators (ESI). It collates numbers of papers published and citations received by the research staff at most institutions in the world. We factor these results by the faculty number to, essentially, scale the score according to the size of the institution. Citation data is taken for the last five years. (Note: this is a change from last year’s 10 years in an effort to enhance the “topicality” of the research)
Conocer nuestra posición en el mundo, debería servir en primer lugar para saber honestamente dónde estamos, más allá de la aldea...Y luego, para preguntarnos qué hacen los otros.
En su introducción, el estudio indica que, en una época donde los estudiantes son estimulados para salir a estudiar al exterior, esta medición está entre los indicadores que serán contemplados al momento de elegir dónde estudiar. Así, indudablemente, no seremos receptores, sino emigrantes.

lunes, diciembre 11, 2006

Texto sobre "Domain Driven Design"

En Infoq se publica un texto gratuito sobre diseño basado en el dominio (Domain Driven Design):
The most complicated aspect of large software projects is not the implementation, it is the real world domain that the software serves. Domain Driven Design is a vision and approach for dealing with highly complex domains that is based on making the domain itself the main focus of the project, and maintaining a software model that reflects a deep understanding of the domain. The vision was brought to the world by Eric Evans in his book "Domain Driven Design". Eric's work was based on 20 years of widely accepted best practices in the object community, as well as Eric's own insights.
Despite the importance of Domain Driven Design, not many people are aware of it, which is why InfoQ commissioned the writing of a 100 page mini-book: Domain Driven Design Quickly, and like all InfoQ books is available for free download as well as print-purchase. The book is a short, quickly-readable summary and introduction to the fundamentals of DDD; it does not introduce any new concepts; it attempts to concisely summarize the essence of what DDD is, drawing mostly Eric Evans' 576 page book, as well other sources since published such as Jimmy Nilsson's Applying Domain Driven Design, and various DDD discussion forums.

domingo, diciembre 10, 2006

Mas sobre Bjarne Stroustrup

Technology Review publica la segunda parte del reportaje a Bjarne Stroustrup.

Problema solucionado...

Después de casi una semana sin acceso desde la página principal, vuelvo a ver mi blog por sus propios medios, sin necesidad de entrar a través de enlaces a ítems individuales. Si bien el problema está en investigación, un parche satisfactorio sugerido por el equipo de Blogger fué reducir el número de posts mostrados a trece días (o menos). Así, dado que de todas formas los posts del mes pueden consultarse en el margen derecho, abriendo el mes que se desee, acepto de buen grado reducir el número de días mostrados.
¡Gracias, y muchas, Blogger Buzzer!

Introducción a Ajax

Mi primer contacto con Ajax se lo debo a mi colega Sergio Guamán, cuando compartíamos área de trabajo en Chile. Desde entonces, no ha dejado de cobrar importancia. David Teare, en Dev2Dev, dedica una pequeña introducción con código incluído a su presentación.

sábado, diciembre 09, 2006

Grace Hopper


En Whatis:
Grace Murray Hopper (1906-1992) was a pioneer of computer science. Hopper is generally credited with developments that led to COBOL, the programming language for business applications on which the world's largest corporations ran for more than a generation. After receiving her Ph.D. in mathematics at Yale, Hopper worked as an associate professor at Vassar College before joining the U.S. Naval Reserve in 1943. She went on to work as a researcher and mathematician at the Eckert-Mauchly Computer Corp. and the Sperry Corporation. Having retired from the Navy after World War II, she returned in 1967 to work at the Naval Data Automation Command. By the time of her death, Rear Admiral Grace Hopper had made many contributions to the field of software engineering and was arguably the world's most famous programmer.
At Eckerd-Mauchly, Hopper developed programs for the first large-scale digital computer, the Mark I. She also developed the first compiler, the A-O. She published the first paper on compilers in 1952. The successor to the the A-O, named FLOW-MATIC, lead to the development of the COBOL programming language. Until then programming was done using assembler language. Admiral Hopper's idea was to make a programming language closer to ordinary language so that it could be used by non-technical people, thus opening the practice of programming to the business world and freeing it from the rarefied environments of science and engineering.
Admiral Hopper remained in the Navy until 1986 and then worked as a senior consultant for DEC until shortly before her death. She was highly sought after as an enthusiastic and entertaining public speaker and educator of young programmers. Hopper was an early advocate of the use of shared code libraries and developed compiler verification software and compiler standards.
Hopper is also credited with applying the engineering term bug to computing when her team found a moth trapped in a relay of the Mark II computer. This particular "bug" was removed, taped to the log book, and now resides at the Smithsonian Institute.
Special note: Today is Grace's birthday, which is why we've featured this computing pioneer as the Word of the Day.
Curiosamente, estaba leyendo sobre Mrs Hopper, tratando de anotar sus datos para Wikipedia en castellano, que aún no tiene una entrada sobre ella, cuando Whatis la recordó en su día.
Quisiera resaltar dos o tres puntos sobre su trayectoria:
Pionera en dos pasos iniciales en los 40 y 50: la serie Mark, y el Univac; autora o coautora del primer compilador en Estados Unidos (el A-O mencionado), del segundo (B-O), y de sus derivaciones al desarrollo del COBOL. Autora de la conceptualización de un "lenguaje" de programación, capaz de expresar instrucciones en una forma entendible para las personas. Miembro fundador de CODASYL.
Y finalmente, hay otro aspecto que quisiera destacar: Mrs Hopper, siendo una matemática, decidió entrar a la fuerza naval de Estados Unidos en plena segunda guerra mundial, con una decisión suficientemente firme para vencer la falta de cumplimentación de requisitos del ingreso. Retirada al fin de la guerra, volvió a servir luego, retirándose con el grado de Comandante (Admiral). Rasgos que la definen tanto a ella como a su país.
Pueden leerse datos biográficos en Yale, Elizabeth Dickason, Saint Andrews, el Agnes Scott College, y el Women's International Center, entre otros. Existe un sitio dedicado a ella.

La fotografía, tomada de la Universidad de Saint Andrews, Escocia.

Bjarne Stroustrup: reflexiones sobre programación

El 28 de noviembre la revista del MIT publica un reportaje a Bjarne Stroustrup, que sigue provocando comentarios:
Some software is actually pretty good by any standards. Think of the Mars Rovers, Google, and the Human Genome Project. That's quality software! Fifteen years ago, most people, and especially most experts, would have said each of those examples was impossible. Our technological civilization depends on software, so if software had been as bad as its worst reputation, most of us would have been dead by now.

On the other hand, looking at "average" pieces of code can make me cry. The structure is appalling, and the programmers clearly didn't think deeply about correctness, algorithms, data structures, or maintainability. Most people don't actually read code; they just see Internet Explorer "freeze."
I think the real problem is that "we" (that is, we software developers) are in a permanent state of emergency, grasping at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but--so often--it's not enough.Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it: a system just "sort of evolved" into something minimally acceptable. Personally, I prefer to know when a system will work, and why it will

miércoles, diciembre 06, 2006

Esfuerzos para exportar TI en Argentina

En La Nación: La Cancillería argentina organizó un seminario para promover al sector de Tecnologías de la Información como nuevo sector exportador, tarea que viene impulsando desde hace ya algún tiempo.
Dijo allí Jonatan Altszul, director de Core Security Technologies, empresa que fundó en la Argentina, pero cuya casa matriz se mudó a Boston, Estados Unidos:
"Estamos ante una oportunidad increíble. Más que exportar software de compañías locales, podemos crear compañías globales desde la Argentina".
"IBM acaba de comprar en US$ 1300 millones la empresa de seguridad informática ISS, de 1300 empleados y con una facturación de US$ 300 millones, es decir, un promedio de ventas de US$ 230.000 por empleado. Core genera US$ 100.000 por empleado. ¿Cuántas compañías argentinas tienen este valor de ventas como las firmas de software?"
Su empresa, con central ahora en Boston, provee servicios de seguridad informática a las agencias de inteligencia de Estados Unidos. La firma tiene su laboratorio en Buenos Aires. En 2007 facturará 20 millones de dólares.
En la reunión, varios participantes apuntaron a criterios requeridos para lograr que TI sea un valor de exportación en Argentina. Varios de ellos están en el centro de los problemas que Argentina debiera revertir:
  • La deserción universitaria (sólo se recibe el 12% de los que ingresan) . En palabras de Carlos Pallotti, presidente de la Cámara de Empresas de Software y Servicios Informáticos (Cessi)
  • La falta de financiación de las pequeñas empresas:"La mayoría de las empresas son pymes, que se financian localmente. El 80% no tiene deudas bancarias, y la razón es que no tienen crédito" (Pallotti)
  • Sobra la capacidad de innovación entre las empresas del rubro, pero falta la capacidad gerencial, para gestionar este tipo de proyectos. (Jonatan Altszul)
  • "Cuidar las formas en la presentación, en los tiempos, aprender a honrar los compromisos sobre la rentabilidad y cultivar el largo plazo".(Roberto Wagmaister, de Grupo ASSA)

lunes, diciembre 04, 2006

La construcción de Windows Vista

En cuanto tenga tiempo, luego de resolver las desapariciones de mi sitio, trataré de entrar en detalle en este artículo de Barrapunto:
"El viernes pasado se habló sobre el disparatado menu de apagado de Windows Vista, en opinión de Joel Spolsky. Ese mismo viernes respondía el programador de esa "característica", Moishe Lettvin, actualmente empleado de Google. Tal como explica Moishe, fue el peor año de su vida y leyendo en qué se ha convertido MS, donde parece predominar la burocracia frente al desarrollo, no me extraña. Es terrorífica en mi opinión la infraestructura arbórea del repositorio de código. Y también quiero destacar la frase: "The end result of all this is what finally shipped: the lowest common denominator, the simplest and least controversial option." Si así es como se ha desarrollado todo Vista, miedo me da el frankenstein en el que haya podido convertir.
(Escrito por Nostromo)

Qué viene después de la Web 2.0? (Según el MIT)

En estos días estoy casi sin tiempo, tratando de resolver el misterioso problema por el que mi blog no aparece si trato de entrar por su página principal, pero sí lo hace si entro buscando un artículo específico...siempre que no vaya a la página de inicio. Estoy tratando de que el equipo de desarrollo y/o soporte de Blogger me escuche (tristezas de estar en un servidor masivo...) pero entretanto apenas queda tiempo para anotar algunas cosas rápido.
Por lo tanto, aquí va un artículo del MIT sobre tendencias para el futuro de la Web...

To see how these ideas may evolve, and what may emerge after Web 2.0, one need only look to groups such as MIT's Computer Science and Artificial Intelligence Laboratory, the World Wide Web Consortium, Amazon.com, and Google. All of these organizations are working for a smarter Web, and some of their prototype implementations are available on the Web for anyone to try. Many of these projects emphasize leveraging the human intelligence already embedded in the Web in the form of data, metadata, and links between data nodes. Others aim to recruit live humans and apply their intelligence to tasks computers can't handle. But none are ready for prime time.
The first category of projects is related to the Semantic Web, a vision for a smarter Web laid out in the late 1990s by World Wide Web creator Tim Berners-Lee. The vision calls for enriching every piece of data on the Web with metadata conveying its meaning. In theory, this added context would help Web-based software applications use the data more appropriately.

Hace tiempo que me pregunto cuánto faltará para que Google intente algo así como un sistema operativo puesto en la Red...

sábado, diciembre 02, 2006

Borland: el cambio viene de afuera

Borland estudia cambios en su estrategia comercial y de desarrollo. Un comentario de Methods & Tools en sus noticias (Facts, noviembre) describe el actual escenario para los participantes históricos:
Borland is separating its development tools group (DTG) in a new subsidiary
named CodeGear. As a subsidiary, the DTG will have its own sales and
marketing strategy. CodeGear will continue to develop the Developer Studio
and JBuilder products. The 2007 version of JBuilder will be built on
Eclipse.
Borland decided earlier that it would like to sell its development tools
division, but, as they said themselves, they were not able to demonstrate
what they believe to be the true value of the business to several serious
bidders. The commercial development tool market is now facing many
difficulties. The main target platform is shifting from workstation to
web-based systems. This decreases the market for languages like C or Delphi
as people shift to PHP or Ruby. Open source tools like Eclipse or NetBeans
provide many functionalities for free. Many commercial editors (excepting
Microsoft) are also offering free editions of their tools. There are
enterprises willing to pay for collaborating features and support, but
those customers are also those that need the higher-costs marketing
efforts. This reduction of margins is responsible for the financial losses
suffered by Borland in the past quarters. My opinion is that the
subsidiary's goal is to provide a better visibility to both Borland and
potential buyers.

martes, noviembre 28, 2006

El próximo Microsoft

"El alma de un nuevo Microsoft", un artículo de Bussiness Week mira hacia adelante en la estrategia futura de negocios de la empresa, destacando a directivos como J. Allard, impulsor de Zune:
Zune hit store shelves on Nov. 14--a mere eight months after Allard's team got the go-ahead for the seemingly impossible task of toppling Apple's iPod music player. Contrast that with the five years and some 10,000 Microsoft Corp. workers it took to give birth to the latest version of the company's Windows operating system, Vista, which begins selling to corporate customers on Nov. 30 (and to consumers in January). From the start, Vista has seemed like an anachronism--packaged software in a Web 2.0 era where ever more applications are moving off the PC and onto the Internet, some springing forth in a matter of weeks
Business Week estima que la empresa debe cambiar ante el creciente asedio de nuevos participantes y nuevas motivaciones:
the point is that Microsoft needs to find its un-Vista. Several of them, in fact. The software giant is entering perhaps the greatest upheaval in its 30-year history. New business models are emerging--from low-cost "open-source" software to advertising-supported Web services--that threaten Microsoft's core business like never before. For investors to care about the company, it needs to find new growth markets. Its $44.3 billion in annual sales are puttering along at an 11% growth pace. Its shares, which soared 9,560% throughout the 1990s, sunk 63% in 2000 when the Internet bubble burst, and they have yet to fully recover.
Y directivos como Allard permiten saltar adelante:
Allard and those like him are having an impact. They're showing that strategies to move the company beyond Windows can emerge and be accepted by top brass as nonthreatening. A key moment came six years ago, when Allard insisted that the new Xbox video game console be developed without using Windows. In one meeting, Gates berated him for suggesting that the operating system wasn't up to snuff. But Allard argued that it wasn't specialized enough to handle video gaming. Gates eventually relented, in a decision that is widely seen today as a key to the console's success.
(...)
That's exactly what Microsoft needs if it hopes to again set the tech agenda. Windows and Office will deliver more revenues in coming years than the exports of many small nations. But Web spitfires such as Google Inc. and Salesforce.com have the wind at their backs. And while Microsoft continues to recruit top talent, it also continues to see key leaders move on: executives such as Vic Gundotra, a top evangelist in its developer division, who will soon join Google, and Brian Valentine, the longtime leader of the Windows server business, who now works for Amazon.com Inc.

PHP en el AS/400

Por si no lo sabía...Hasta hace muy poco, no era posible usar PHP en un ISeries (o AS/400, o I5). Desde abril de este año, esto ha cambiado: Zend Technologies Ltd ofrece ahora una implementación. El artículo en IBM developer ofrece información introductoria y de implementación.
PHP on System i is a great benefit to small and medium businesses. After understanding the basic background and architecture types of PHP, you can download and install thousands of available applications on System i, either by themselves or with a supported database. There are considerations when porting an application from the MySQL database to DB2, such as database connectivity. However, the cutting edge, low-cost applications that PHP offers combined with the solid System i platform and DB2 database make a strategic choice for any growing business.
Características actuales de la implementación (dada una, probablemente veremos otras):
System i users have several issues to consider when choosing an open source application. The first and probably most direct issue is selecting from the diversity of existing applications. Zend Core is the only PHP engine currently available for i5/OS on the System i platform. Before installing Zend Core, you need to install 13 licensed programs included with the System i software package (see Table 1). The introduction of the Zend Core framework for i5/O has greatly simplified installation of PHP on System i computers. Zend's setup tool provides the System i platform with the PHP engine, Apache HTTP Web server, DB2 native support, and Web GUI administration.
The Zend Core product is a free, licensed product. The installation involves creating a SAVF file on the System i and copying the Zend Core to the file in binary. The Zend Core includes detailed instructions with its download from the company Web site (see Resources).
By installing Zend Core, the associated PHP Apache Web server is configured. You can easily perform additional customization of the framework using the GUI administration page through a Web browser. The Zend PHP engine is currently supported only on i5/OS Version 5 Release 4.

domingo, noviembre 26, 2006

Juan Freire: el uso de la Web en la escuela media española

El excelente blog de Juan Freire se ocupa del uso de tecnología Web 2.0 en la enseñanza media española:
(...) en enseñanzas medias, en algunos casos, son las propias instituciones (los centros y las comunidades autónomas) los que han comprendido la necesidad de introducir Internet en la enseñanza y han apoyado estrategias en este sentido. Siendo minoritarias estas iniciativas (y aún más minoritarias las que desarrollan estrategias eficaces), constituyen un cambio cualitativo al constituirse en ejemplos de buenas prácticas que otras instituciones y profesores pueden seguir. Las estrategias de las universidades son, en el mejor de los casos, aún incipientes, en la mayoría inexistentes y, en algunos otros, totalmente perversas al fomerntar estándares cerrados y reducir la capacidad de colaboración
Léalo, y tómelo como una guía de orientación en los esfuerzos por entender el poder de las nuevas herramientas para la construcción de conocimiento. (Como siempre, enlace en el título de esta nota)

Ley de educación argentina casi completada

La semana pasada se concretó el envío de la nueva ley de educación al congreso nacional, en una ceremonia de consenso:
Asistieron los presidentes de la Unión Industrial Argentina, Héctor Méndez; de la Sociedad Rural Argentina, Luciano Miguens; de la Comisión de Educación del Episcopado, monseñor Guillermo Garlatti; de la Asociación de Bancos Argentinos, Mario Vicens, y del Consejo Superior de Educación Católica (Consudec), hermana Gladis Uliarte, además de gobernadores y legisladores. Estaban, además, Hugo Yasky, titular de la Ctera y de la Confederación de Trabajadores de la Argentina (CTA); Hugo Moyano, de la Confederación General del Trabajo (CGT); Juan Carr, de la Red Solidaria; Margarita Poggi, directora del Instituto Internacional de Planeamiento Educativo de la Unesco; rectores de las universidades, y representantes del ámbito académico y de organizaciones de derechos humanos, entre otros.
Este consenso refleja un trabajo previo de consulta de medio año que es mencionado como un gran esfuerzo de millones de participantes por el ministro de educación:
Filmus celebró la posibilidad de encontrarse "en un clima de pluralidad" 180 días después de lanzar, en mayo último, el debate por la ley de educación. "Permítanme creer que están reflejadas las aspiraciones y los sueños de la mayoría de los argentinos en este proyecto de ley que enviamos al Congreso", expresó. Y se refirió "al esfuerzo que han hecho las más de cuatro millones de personas que participaron del debate"
Este período de consulta sin embargo no parece suficiente para lograr un buen debate, sino más bien para consensuar un proyecto ya definido. Dice un editorial de La Nación:
Esta vez, los educadores y los diferentes actores sociales interesados por la educación se vieron involucrados en el debate. En efecto, pareciera que el Ministerio de Educación supo escuchar y tomar debida nota de los aportes y las críticas que la ciudadanía había ido expresando a través de sus organizaciones. Debe destacarse la prudencia y el esfuerzo realizado por el ministro para incorporar distintas posiciones y acordar consensos fundamentales que quedaran plasmados en el articulado de la futura norma en sus dos fases de redacción.
A lo largo de seis meses, pues, se han realizado numerosos actos de difusión y jornadas de reflexión y debate de propuestas, en los que participaron miles de docentes, padres, más de 700 organizaciones de la sociedad civil, sindicatos de docentes y no docentes, y centenares de académicos, intelectuales, dirigentes gremiales, empresarios y representantes de organizaciones de la sociedad civil. Esta original forma de elaborar una norma le otorgará a la futura ley legitimidad social y, además, señala el camino a través del cual deberá aplicársela.
Algunas de las características de la nueva ley:
Un análisis profundo del proyecto presentado muestra que intenta corregir las deficiencias del texto legal que lo precedió, la ley federal de educación, para alcanzar soluciones efectivas y realistas. Entre otras, además de restablecer la tradicional división entre escuela primaria y secundaria, están la recuperación de la responsabilidad del Estado nacional, como garante del derecho a la educación y al conocimiento; la asignación de una inversión no inferior al 6 por ciento del producto bruto, destinada exclusivamente al sector educativo; la escuela secundaria obligatoria, que extiende el total de la escolaridad obligatoria a trece años; la jornada extendida o completa para las escuelas primarias, lo cual permitirá la incorporación de nuevas actividades educativas; la reforma curricular e institucional de la escuela media; la enseñanza obligatoria de una segunda lengua y de las nuevas tecnologías de la información, y se explicitan un conjunto de medidas destinadas a mejorar la calidad de la educación.
También en el articulado se resguarda debidamente la libertad de enseñanza y se restablece la importancia de la formación docente inicial y continua en el nivel nacional.
El proyecto define a la educación como "un bien público y un derecho personal y social, garantizados por el Estado". (...) Fija la obligación del Estado de garantizar la oferta de la sala de jardín de infantes de cuatro años y da carácter vinculante para las provincias a las decisiones del Consejo Federal de Educación. [La Nación, 17-11-06]
Establece el mejoramiento de la formación de los docentes como un factor clave de la calidad de la educación, crea el Instituto Nacional de Formación Docente y admite dos modalidades en la carrera docente, al prever ascensos y promociones sin dejar el aula y en la gestión directiva.

Un aspecto negativo en la presentación: aparece una discordancia representada por uno de los pilares que deberá construír la reforma: la posición de los gobernadores provinciales. La explícita oposición del gobernador de Salta expresa uno de los problemas estructurales que Argentina debe afrontar y resolver: su organización federal, y la independencia, autonomía o aislamiento, según sean las posibilidades de la provincia de que se trate. ¿Quién aplicará la reforma?
Dice el gobernador:
"La letra del documento es dañina para los Estados provinciales ya que sobre sus administraciones cayó la obligación de la Educación cuando en 1991- fueron traspasados los establecimientos nacionales".
En ese sentido, explicó que "el anteproyecto de ley dispone acerca del porcentaje presupuestario que se va a destinar a Educación, con lo cual usurpa facultades de las Legislaturas provinciales, a las cuales les corresponde establecer los respectivos presupuestos anuales de gastos"
(...) [Señaló la intención] de sustituir al legislador provincial del tratamiento de leyes de esta naturaleza. Según interpreta, las mismas suponen la consulta a los Estados provinciales, los que "solamente pueden expresar su voluntad a través de instituciones y no mediante un organismo ad-hoc (el Consejo Federal de Educación) generado en el ámbito del Ministerio nacional de Educación".
(...) No se puede hablar de un sistema educativo nacional porque para consensuar un régimen único resultaría necesaria la creación de la figura de una "ley convenio", a la que pudieran adherir las Provincias: "A partir del momento en que los establecimientos educacionales pertenecen a las Provincias y son dirigidos y mantenidos por éstas, las cuales pagan el sueldo a los respectivos docentes, mal puede hablarse de un sistema educativo nacional".

sábado, noviembre 25, 2006

Bijay Jayaswal y Peter Patton sobre métricas de calidad

Developer publica un artículo sobre métricas de software que tiene la virtud de estar soportado por una visión de la calidad que supera el usual enfoque "especialista". Son destacables tres aspectos: la recuperación de la importancia de los teóricos de Calidad Total (TQM) en los orígenes de la disciplina; la atención dedicada a los problemas de arquitectura (a propósito, los autores entregan también una definición de arquitectura); y la discusión de las métricas específicas al paradigma del análisis y la programación orientada a objetos. Sus puntos principales desarrollados:

  • Historically software quality metrics have measured exactly the opposite of quality—that is, the number of defects or bugs per thousand lines of code.
  • Software is a multidimensional concept that can be viewed from many professional and user viewpoints.
  • Two leading firms in customer-focused software quality are IBM and Hewlett-Packard.
  • IBM has a proprietary measure set, whereas HP uses five Juran quality parameters.
  • The Naval Air Systems Command coined the term Total Quality Management (TQM) in 1985 to describe its own quality improvement program. It soon spread worldwide.
  • The four essential characteristics of a TQM program in any field are customer focus, process improvement, quality culture, and measurement and analysis.
  • TQM made an enormous contribution to the quality of enterprise software in the early 1990s, just in time for the Y2K transition.
  • Until recently, most software quality metrics were of an in-process nature; metrics to support DFTS must be applied upstream in the development process.
  • Small programs (less than 100 LOC) exhibit 1.5 defects per KLOC. Large programs (more than 1,000 LOC) exhibit 1.5 defects per KLOC. Medium-sized programs often have only 0.5 defects per KLOC.
  • Sophisticated software tools for measuring software quality, such as PAMPA, are beginning to appear.
  • OOP goals in software reusability tend to enhance software quality as well.

Breve introducción a las arquitecturas

Dejando de lado las referencias más específicas a Websphere, un artículo de Bobby Wolf en el sitio de IBM dedicado a desarrolladores ofrece una introducción al alcance de las arquitecturas de software. Cuatro aspectos de interés:
  • La descripción de las organizaciones con una arquitectura no planificada, espontánea o no-arquitectura.
  • La breve historia de las arquitecturas en general adoptadas
  • La definición de un arquitecto de IT
  • ...y la introducción a las arquitecturas orientadas a servicio (SOA)
En principio, una definición:
The architecture of a system is the highest level of shared understanding of that system by the experts who create it. It is the main parts of the system that need to be understood so that the system, the main components, and how they relate and interact can be understood. An architecture is whatever the expert designers find important at the top level; the architecture drills down into important details while less important ones are determined at lower levels of design. (...)
If the entire system is considered the topmost level of interest, that's the enterprise architecture. If you're focusing on the hardware and low-level software the system runs on, you're concerned about the infrastructure architecture. Even that may be high level for someone focused on the network architecture, in which the network is considered the highest level of interest. Others focus exclusively on the storage architecture. Operations architecture involves keeping the production system running smoothly even during challenges like load spikes and outages.
Una arquitectura no planeada, cae en alguna de estas categorías, según Wolf:

There are three general types of these non-architected architectures, each with its own derogatory yet memorable name:

Big ball of mud (a.k.a. Shantytown) -- This kind of system contains large segments that are unused. Yet the unused parts are so enmeshed with everything else that they're impossible to identify, much less remove.

Spaghetti -- This is a system with no logical flow, where any part may be connected to any other part. In such a case, most of the parts share some dependency on many or most of the other parts, even if such dependencies make little difference to the overall functionality of the system.

House of cards -- With this non-architecture, every part depends on many others, so that a change to one part breaks several, and fixing one problem introduces many more.

Many systems with the properties of one type tend to have the properties of the other two types as well. The figure below shows an example architecture that has characteristics of all three types.

Sobre la historia de las arquitecturas:

The following are major milestones in IT architecture, listed in roughly chronological order:

  • Mainframes. The first applications ran on one central computer. Users connected through dumb terminals or teletype machines. Architecture was simple: The application did everything beyond the operating system. For persistence, there was no external database like IBM DB2® or Oracle--the application stored its data in files itself. There were no messaging systems, no GUIs, no shared data, and no interaction between applications.
  • Workstations. As desktop computers became common, so did applications that ran on them. These are personal productivity applications like VisiCalc, WordPerfect (now published by Corel Corporation), and the Microsoft® Office applications. These were personal applications; each user ran a locally installed copy and quit it after its use. No data was shared; it was stored in files on local disk and only distributed by sneaker-net.
  • Networking. Networks connected workstations to each other, to shared server computers, and to mainframe-style central processing computers. This enabled e-mail capability within an enterprise and sharing files on a file server.
  • Client/server. Networking enabled client/server computing, where the application no longer ran completely on a central computer or on a workstation, but was split across the two. Original client/server applications ran on the workstation but accessed centralized data from a database server. Later architectures split the application itself into two parts: a shared component for business logic that ran on the server and local clients that implemented the user interface. The need to host this central business logic led to the development of application servers for running and managing the server part of the application.
  • N-tier. A client/server architecture is said to be a two-tier architecture. When the database server runs on a different host computer from the application server, that's a three-tier architecture. As network-based applications became more sophisticated, designers divided the application stack--from the GUI to the database--into more processes on both the client and the server. Such a multiple-tier design became generically known as an n-tier architecture.
  • Internet. The Internet is networking on steroids, a global network. The Internet is actually older than the networks in most enterprises, but it was impractical to access it in the business world until an enterprise constructed an internal network that could connect to the Internet. The Internet enabled communications and information sharing not just between users in an enterprise, but between users anywhere in the world.
  • World Wide Web. The Web made the Internet graphical. It enabled authors to publish words and pictures--using Hypertext Markup Language (HTML)--as a combined document that could be viewed by anyone anywhere in the world. These HTML documents contained hyperlinks to other documents, so any reference to another document became active and provided the reader direct access to the referenced source. This was the beginning of information on demand, to links being as important as nodes.
  • Browser GUIs. The Web introduced HTML browsers for viewing static HTML documents. This paradigm was quickly adapted to provide interactive GUIs for accessing remote applications. This was a return to the centralized computing model. It wasn't actually a client/server model, because practically none of the application ran on the client except for HTML rendering and some simple scripting. Even the validation of input values had to be performed on the server.
  • Web services. The Internet was created to connect applications, but the Web connected people to static content and to server applications. Web services use the Web to connect applications so that one application can invoke behavior in another application through a Web connection.
  • Web 2.0. This is the application of Web services to Web sites. The user of a Web site is no longer a person, it's another application.
  • Service-Oriented Architecture (SOA). Applications have tended to be monolithic, running entirely either on a central computer or on a workstation. Client/server and n-tier architectures distributed application layers; browser GUIs moved the application back to the server. Even with n-tier architectures, this architecture was still rather monolithic because the run-time stack is self-contained; applications at best interacted as peers. SOA divides an application into a service coordinator (the top set of consumers in a composite application) that represents user functionality and service providers that implement the functionality. While the coordinator tends to be unique to a particular application, a service can be reused and shared by multiple composite applications.
  • Event-driven architecture. With SOA, the service coordinator explicitly specifies and invokes the desired services. With event-driven architecture (EDA), an application detects an event and emits a notification; other applications have handlers that can receive the notifications and react by invoking services. In this way, the detection application doesn't have to know all the services it should invoke in response to an event; it can simply announce the event and let the other applications decide which services to invoke in response.
La definición de IBM sobre quién es un arquitecto (seis disciplinas):
  1. Enterprise architecture. An enterprise architect focuses on mapping IT capabilities to business needs. The architect is responsible for an enterprise's full range of software-intensive systems, including the relationship between multiple applications, data shared between applications, integration of the applications, and the infrastructure to run applications.
  2. Application architecture. An application architect focuses on the design of applications to automate business processes and provide functionality that helps users perform business tasks. The architect's responsibilities include designing the application to meet user functional and quality of service requirements including performance, availability, scalability, security, and integrity. Responsibilities also include evaluating and selecting the software and hardware necessary to run the application, as well as the tools and methodologies to develop the application.
  3. Information architecture. An information architect focuses on the data used by multiple applications, including the structure, integrity, security, and accessibility of that data. The architect's responsibilities include designing, building, testing, installing, operating, and maintaining the systems for managing that data. Design of these systems must account for data requirements such as source, location, integrity, availability, performance, and age.
  4. Infrastructure architecture. An infrastructure architect focuses on the design of hardware and server software including server computers, storage, workstations, middleware, non-application software, networks, and the physical facilities that support the applications and business processes required by the enterprise. The architect's responsibilities include evaluation and selection of these components; modeling, simulating, and testing to validate the designs and selected products; and performance, availability and scalability of the resulting infrastructure.
  5. Integration architecture. An integration architect focuses on the design of solutions that enable existing applications, packaged software offerings, networks, and systems to work together within an enterprise or among enterprises. These solutions may use different technologies, vendors, platforms, and styles of computing.
  6. Operations architecture. An operations architect focuses on the design of solutions to manage the infrastructure and applications used by the enterprise. The architect's responsibilities include defining plans, strategies, and architectures for the installation, operation, migration, and management of complex information systems.
These architects do not work independently because their domains overlap. The infrastructure architect designs the foundation the systems run on. The application architect designs the programs for users, the integration architect makes sure the programs can be integrated, and the information architect makes sure they have data. The operations architect makes sure it all runs properly, and the enterprise architect oversees all of these aspects and ensures that they all come together.
SOA es desarrollada por separado, en un área completa

Dificultades de las "máquinas de pensar"

Danny Hillis, con excepticismo pero también con entusiasmo, habla en la revista del MIT, de las "máquinas de pensar" y otros mecanismos de análisis complejo:
We look to our own minds and watch our patterns of conscious thought, reasoning, planning, and making analogies, and we think, "That's thinking." Actually, it's just the tip of a very deep iceberg. When early AI researchers began, they assumed that hard problems were things like playing chess and passing calculus exams. That stuff turned out to be easy. But the types of thinking that seemed effortless, like recognizing a face or noticing what is important in a story, turned out to be very, very hard.
Por qué falló en su intento de desarrollar una "máquina de pensar":
Well, the glib answer is that we just didn't have enough time. But enough time would have been decades, maybe lifetimes. It is a hard problem, probably many hard problems, and we don't really know how to solve them. We still have no real scientific answer to "What is a mind?"
Sobre la aplicación de computación a la biología:

TR: You were ahead of your time in applying computation to immunology, genetics, and neurobiology. Today, computation is ubiquitous in biology. What will this mean?

Hillis: I am excited that computational biology is coming into its own. It feels like the field of computing did in 1970. Everything seems pos­sible, and the only constraint is our imagination. There are still so many basic, simple questions that are unanswered: "How are memories encoded?" "How does the immune system have a sense of ‘self'?"

I am especially interested in what will come of computational models of evolution, although I have to admit that the field seems a bit stuck right now. Most current models of evolution reduce it to a very weak kind of search algorithm, but I have always felt that there is something more to it than that. It is not that the biologists are wrong about the mechanisms, but rather that the models are much simpler than the biology. It may be that the interaction of evolution and development is the key, or behavior and environment, or something like that.

"la calidad no es mi problema"

Alan Koch escribe en CM Crossroads acerca de los roles en la construcción de software de calidad, apuntando a un problema común: la separación de funciones diluye la responsabilidad en la obtención de un producto de calidad, y en la raíz del problema está el hecho de que ésta no se obtiene a posteriori, sino que se construye con el producto. Por lo tanto, su obtención es responsabilidad del proceso de construcción en sí (y sus actores):
Testers Don’t Assure Quality
(...) one of the premises for the “Quality is not my job” syndrome is the idea that the testers are responsible for assuring the quality of the product we are building. It turns out that this is not the case. Although the testers’ job revolves around quality, it is more about measuring quality that it is about assuring it.
Yes, testers find problems, which get fixed resulting in fewer problems. But do we ever expect the testers to find all of the defects in the product? We shouldn’t, because the complexity of our systems makes that an unreasonable expectation. The main value of testing is to demonstrate the degree to which the product can be trusted to satisfy the customers’ needs.
There is an important truism that says, “You can’t test quality into the product; it must be built in.” [El subrayado es mío] If quality must be built in, then who should be accountable for the quality of the product? Those who build it are the only people we can look to for a high-quality product. The developers are the source of the quality (or lack there of) that the testers measure.
¿Cómo se debe manejar la calidad? Como una visión global, una cultura de calidad:
A Culture of Quality
While it is advisable to integrate product quality into our developers’ accountabilities, this will work best within the context of a culture of quality. We need an organization that values the quality of what is done just as surely as it values productivity and speed.

In a quality-oriented organization, every individual is conscious of the quality of the end product and their own contributions to it.
  • The developers strive for high-quality designs and code, not just for the sake of technical elegance, but mainly so it will satisfy the customer. Rather than slinging code, they carefully engineer a system.
  • The Business Analyst strives not just to document the requirements, but mainly to provide the foundation the developers will need to build the right thing. Rather than merely writing a specification, the BA is the liaison between the customer and the developer, assuring that they understand each other.
  • The project Manager strives not just to build a good plan and manage activities, but mainly to establish the environment in which the team can build the product the customer needs and deliver it when the customer needs it. Rather than giving orders and demanding results, the pM is enabling each team member to do his or her job well.
  • The tester strives not just to find defects and point fingers, but mainly to determine the degree to which the product as it was built will actually meet the customer’s needs. Rather than telling the developers how bad their code is, the tester is helping the developers to do a better job on this project than they did on prior ones.
In an organization like this, no one will say, “Quality is not my job.” Rather, everyone is conscious of the ways in which quality is a part of their jobs.
Las afirmaciones de Koch remontan a los conceptos de Calidad Total, y han recorrido un ya largo camino en la industria. A pesar de las opiniones de muchos desarrolladores, contrarios a las ideas de emplear sistemas "fabriles", encontrarían muchas ideas estimulantes en el estudio de la evolución de los métodos de fabricación de los últimos treinta o cuarenta años (Lean Manufacturing, Just in Time)

viernes, noviembre 24, 2006

Estados Unidos: Alza tecnológica sin burbuja

Cristina Triana publica en El economista de España una nota sobre el alza actual de la cotización accionaria de las empresas tecnológicas en Estados Unidos. Algo que se advierte desde hace algún tiempo, como lo ha demostrado Google, rompiendo la tendencia a la retirada del mercado de acciones. Las cifras comparativas de Triana muestran una situación en general saludable de las empresas, con valores que aún están por debajo de los valores alcanzados durante la burbuja:

(...) Los inversores se encuentran mucho menos dispuestos en 2006 -excepto en el caso de algunas compañías concretas- que hace seis años a pagar cualquier precio por tener en sus manos títulos de una tecnológica, a pesar de que las que resistieron la lluvia de números rojos post 2000 eran las mejores, según los expertos. "El estallido de la burbuja tecnológica propició la desaparición de las compañías que habían surgido y que únicamente se sustentaban en el momento y no en su negocio"

miércoles, noviembre 22, 2006

La estrategia de Microsoft en modelado vs MDA

Un importante punto de inicio para discutir otros argumentos. Se trata de un documento de Microsoft de octubre de 2005, que aunque no sea muy reciente, es más constructivo que otros documentos posteriores.
Imagínese Software Factories como MDA incorporado y ampliado, donde MDA se define con un sentido más amplio que la definición oficial basada en PIM y PSM. Software Factories van más allá de la independencia genérica de la plataforma y los modelos específicos. (...)
MDA, según lo define OMG, sólo trata una pequeña parte de lo que creemos que son problemas reales que deben solucionarse para permitir un desarrollo eficaz controlado por modelos.
Incluso resulta de mucho interés la descripción de algunos objetivos deseables en el marco de una mayor rigurosidad en la construcción de software:
¿Qué se debería modelar para un tipo de sistema determinado? Puesto que distintos sistemas pueden tener arquitecturas diferentes, ni un sólo conjunto de modelos puede describir todos los sistemas posibles de forma efectiva. La respuesta a esta pregunta variará entonces según los diferentes tipos de sistemas. En nuestra opinión, un único PIM y un solo PSM por plataforma de destino, desarrollados todos con un lenguaje de modelado de finalidad general, como prescribía MDA, no son suficientes para admitir los niveles considerablemente superiores de automatización que promete el desarrollo controlado por modelos. La automatización enriquecida del ciclo de vida del software requiere numerosos tipos de modelos adicionales como, por ejemplo, modelos que:
• Capturan, analizan y administran los requisitos; identifican las relaciones de seguimiento entre los requisitos, diseño arquitectónico y construcciones de implementación, permiten la validación de que se implementan los requisitos y permiten el análisis del impacto cuando cambian los requisitos.
• Definen la arquitectura del software de modo que admita la seguridad, el análisis del rendimiento y la confiabilidad, así como otras formas de evaluación, de manera que permita un ensamblado de sistemas predecible a partir de componentes y transformaciones paso a paso eficientes y reversibles de requisitos e implementación.
• Definen cómo se empaquetan los componentes ejecutables del sistema, identificando los tipos de recursos del entorno de desarrollo que necesita cada componente y enlazando los componentes a instancias específicas de dichos tipos de recursos.
• Definen casos de pruebas, realizan pruebas en los conjuntos de datos, en el sistema de seguridad y en otros artefactos, de forma que facilitan el proceso de evaluación de la calidad del software desarrollado mediante modelos y la administración y visualización de los resultados de las pruebas.
• Identifican las relaciones de seguimiento entre los modelos y los demás artefactos, de modo que facilitan el análisis del impacto empresarial cuando los sistemas dejan de funcionar, configuran los sistemas para satisfacer los requisitos y aplican limitaciones durante la configuración del sistema.
• Define configuraciones de artefactos de origen utilizados para crear ejecutables, facilitar la creación de versiones de dichas configuraciones y asociar informes de defectos y solicitudes de cambios de características asociados con versiones específicas.
Invariablemente, estos requisitos son vistos como elementos que invalidan el esquema sugerido por OMG, y remiten a la solución de Software Factories como camino acertado, afirmación que a más de un año de este documento sigue siendo una promesa, y una visualización de futuro.
Por eso mismo, insisto en que estas puntualizaciones deben ser tomadas como parte de una lista de tareas para discutir, en un camino convergente de soluciones, donde las realidades de múltiples herramientas practicando sobre las lineas sugeridas por el estándar de Desarrollo Orientado por Modelos de OMG, compitan con las virtualidades de Software Factory, y aún otras propuestas existentes.
Contrariamente a las afirmaciones actuales de los sostenedores de SF, en 2005 el enfoque era más abierto:
Algunas organizaciones que buscan un desarrollo controlado por modelos aceptan una interpretación más amplia del término MDA que la que prescribe OMG; de hecho, como hemos descrito, deben hacerlo para poder lograr el éxito. El uso de cualquiera de las especificaciones de OMG en el desarrollo controlado por modelos se marca normalmente como MDA, incluya o no PIM y PSM. Algunas organizaciones, por ejemplo, consideran la especificación MOF de OMG clave para MDA. Esta consideración se basa en los nuevos lenguajes de modelado definidos con MOF, no los predefinidos en UML, y son similares en efectividad a nuestro enfoque. (...)
Imagínese Software Factories como MDA incorporado y ampliado, donde MDA se define con un sentido más amplio que la definición oficial basada en PIM y PSM. Software Factories van más allá de la independencia genérica de la plataforma y los modelos específicos para tratar los problemas descritos en la sección anterior.
En cuanto a uno de los pilares de MDA, como ya es sabido, la posición era y es la misma:
En resumen, recomendamos el uso de UML y las herramientas basadas en UML para:
• Realizar bocetos.
• Escribir en pizarras blancas.
• Documentación.
• Dibujos conceptuales que no están directamente relacionados con el código.

Recomendamos DSL y herramientas basadas en DSL definidas de forma precisa para:
• Abstracciones precisas con las que generar código
• Abstracciones precisas que asignan puntos de variación en los marcos y componentes.
• Asignaciones precisas entre lenguajes DSL.
• Dibujos conceptuales que tengan asignaciones que se puedan especificar de forma precisa en otros lenguajes DSL o en artefactos de código.

No recomendamos nada de lo anterior en el caso de programación visual de lógica detallada de programas (o por lo menos no hasta dentro de varios años).
Este también es uno de los puntos donde disiento particularmente: No es más ni menos riguroso el mapeo que se ejecute entre un diagrama UML y el código, que el que pueda hacerse entre una herramienta DSL y el código. Esto sin hablar del hecho de que reemplazar el ahora odioso diagrama "genérico" UML por un lenguaje específico de dominio no será una tarea trivial, capaz de poner en manos de un desarrollador medio. Estamos hablando aquí de: o comprar n herramientas "de dominio" para cubrir la articulación de la arquitectura elegida (y resolver su integración), o dedicar un(os) equipo(s) de desarrollo a la forja de los DSL requeridos para el problema específico.
Que el UML como lenguaje no sea suficiente para generar lógica detallada, y que tampoco lo sea un DSL ("No recomendamos nada de lo anterior en el caso de programación visual de lógica detallada de programas -o por lo menos no hasta dentro de varios años-"), es algo que pone la escritura de código "a mano" como parte principal del desarrollo, con lo que no difiere mucho una SF de un marco para la administración de configuración. Sinceramente, los intentos tipo MDA se proponen mayores logros.

sábado, noviembre 18, 2006

El tratamiento post-mortem de un proyecto

Mike Gunderloy dedica un artículo en Developer.com al cierre post-mortem de un proyecto, considerándolo con razón una herramienta de importancia en su manejo en el tiempo, denominándo la técnica "memoria institucional".
Though the name is well-established by now, "postmortem" has somewhat unfortunate connotations. The purpose of a good software postmortem isn't to carve up the corpse of a collapsed software project so as to assign blame for failure (though in dysfunctional organizations postmortems get used this way anyhow). Rather, the goal is to build up an institutional memory and develop a set of best practices that work for your own organization by meticulously recording what went right and wrong over the course of a project.
(...)
The difference between an organization with a culture of postmortems and one without can be dramatic. This is probably in part because of the good effects of postmortems, and in part because companies that lack the discipline to perform postmortems tend to be at a rather chaotic level of practice. When postmortems are institutionalized, you'll find people saying things like "we organize our source code tree this way, because we've found in the past that it works well" or "we stopped using that particular risk assessment practice because it just wasn't giving us any useful information." Without postmortems, developers are more likely to invent techniques as they go along, without much regard for what may or may not have worked in the past - and more likely to be surprised when something fails for the second (or third, or tenth) time.
(...)
Software postmortems, performed consistently, are a key part of bringing a development organization from chaos to smooth, repeatable functioning. In fact, if your development efforts are completely disorganized, postmortems can be a great way to start turning things around, because they will help you identify and keep the good parts while finding and throwing out the bad parts. If you're not already using this essential tool, it's never too late to start.
Gunderloy da nueve sugerencias para su elaboración:
Planear las actividades:
People need to have time to think without being thrown immediately into the next project. The postmortem should be a scheduled activity, with time for a meeting of the team to discuss the lessons learned and time for someone (or some group) to write the postmortem report
No dejar pasar mucho tiempo:
Don't let memories fade by scheduling the postmortem too long after the end of the project. Ship the software, have the celebration, and then roll right into the postmortem, rather than waiting for a convenient break in the action (which never comes, anyhow) a month or two later
Registrar los detalles:
Part of the postmortem report needs to be a recital of the details of the project: how big it was, how long it took, what software was used, what the objectives were, and so on. This is not padding, but a way to help people looking for applicable experience in the future. If you build up a library of dozens of postmortems, a team about to embark on a 5-person, 6-month effort can use the project details to look for similar projects that the organization has tackled in the past
Involucrar a todos los participantes:
You need to collect them all to really understand what worked and didn't.
Registrar tanto los aspectos exitosos como los fallos:
It's easy for a postmortem to degenerate into a blame session, especially if the project went over budget or the team didn't manage to deliver all the promised features. But people need to hear positive messages as well as negative ones, and they need to hear what things are worth repeating as well as which things are worth avoiding in the future.
No debe ser un argumento de penalizaciones:
If you want honest postmortems, management has to develop a reputation for listening openly to input and not punishing people for being honest. And the way to get that reputation is by not punishing people.
Establezca un plan de acción:
The written postmortem should make recommendations of how to continue things that worked, and how to fix things that didn't work. Remember, the idea is to learn from your successes and failures, not just to document them
Hágalo disponible:
If you're the one responsible for producing one, you should consider sending out an e-mail at the end of the process saying something like, "The XYZ project postmortem is finished and available at \servershare. We recommend that future teams do a, b, and c and avoid d, e, and f. For more details, feel free to read our whole postmortem."

viernes, noviembre 17, 2006

Software Factory según Chillicoder

Martín Trejo, autor de Chillicoder , dedicó en julio de este año un artículo a Factorías de Software, que tiene la virtud de describir las condiciones que impulsan hacia formas más "industriales" de construír software. Y también una introducción a los recursos desplegados por Microsoft en este terreno, particularmente Guidance automation Toolkit. Continuará...

miércoles, noviembre 15, 2006

En Bloginnova:I+D en Finlandia, analizada en Bruselas

El próximo 10 de noviembre se celebra en Bruselas un seminario sobre los recientes instrumentos finlandeses y de la UE orientados a generar un entorno próspero de investigación y desarrollo (I+D) e innovación.
El seminario fue inaugurado por Anita Lehikoinen, Directora del Departamento de Educación y Política Científica en el Ministerio finlandés de Educación, quien habló sobre la estrategia de enseñanza superior de Finlandia como un requisito previo para el rendimiento del país en I+D e innovación, y sobre la necesidad de internacionalizar la estructura de investigación de Finlandia.
El Presidente de la Academia de Finlandia, el Profesor Raimo Vayrynen, también se hizo eco del reto de la «internacionalización», y señaló los recientes esfuerzos de la Academia y Tekes, la Agencia finlandesa de financiación de la Tecnología e Innovación, para situar el sistema finlandés de investigación en la arena mundial.

lunes, noviembre 13, 2006

Java marcha a GPL

Stefan Tilkov, como varios otros, adelanta el anuncio del paso de Java a GNU General Public License v2 (GPLv2). Una gran noticia, de primera importancia para los próximos tiempos.
Algunas repercusiones en Tim Bray, InfoQ, Barrapunto, y especialmente, en Sun.

viernes, noviembre 10, 2006

Surgimiento y declinación de CORBA (Michi Henning)

Este artículo tiene varios meses de publicado, pero su análisis sigue siendo válido, no sólo porque es retrospectivo, sino también porque se pueden deducir conclusiones vistas a futuro, especialmente en cuanto a la posibilidad de construír estándares apoyados en consorcios de la industria.
Resumiéndolo a cuatro palabras:
CORBA 2.0 se inició con éxito y popularidad al resolver el problema de desarrollo en sistemas heterogéneos:
It provided a standardized protocol and a C++ language mapping, with a Java language mapping following in 1998. This gave developers a tool that allowed them to build heterogeneous distributed applications with relative ease. CORBA rapidly gained popularity and quite a number of mission-critical applications were built with the technology.
La aparición de Java, por un lado, y el crecimiento acelerado de la Web, presentaron un desafío a la consolidación del estándar:
CORBA provided a Java language mapping, but it did nothing to cooperate with the rapidly exploding Web. Instead of waiting for CORBA to deliver a solution, companies turned to other technologies and started building their e-commerce infrastructures based on Web browsers, HTTP, Java, and EJB (Enterprise JavaBeans).
El estándar resultó complicado de utilizar frente al nuevo escenario:
Many of the APIs were complex, inconsistent, and downright arcane, forcing the developer to take care of a lot of detail. In contrast, the simplicity of component models, such as EJB, made programming a lot simpler (if less flexible), so calls for a CORBA component model became louder and louder.
CORBA resultó además caro y de lento aprendizaje:
Commercial CORBA implementations typically cost several thousand dollars per development seat, plus, in many cases, runtime royalties for each deployed copy of an application. This limited broader acceptance of the platform—for many potential customers, CORBA was simply too expensive.
The platform had a steep learning curve and was complex and hard to use correctly, leading to long development times and high defect rates. Early implementations also were often riddled with bugs and suffered from a lack of quality documentation. Companies found it difficult to find the expert CORBA programmers they needed.
Por otra parte, Microsoft no apoyó CORBA, y desarrolló su propio estándar, con pérdidas por ambos bandos:
Microsoft never embraced CORBA and instead chose to push its own DCOM (Distributed Component Object Model). This kept much of the market either sitting on the fence or using DCOM instead, but DCOM could not win the middleware battle either, because it worked only on Windows.
La aparición de XML transformó el escenario:
Another important factor in CORBA's decline was XML. During the late '90s, XML had become the new silver bullet of the computing industry: Almost by definition, if it was XML, it was good. After giving up on DCOM, Microsoft wasn't going to leave the worldwide e-commerce market to its competitors and, rather than fight a battle it could not win, it used XML to create an entirely new battlefield. In late 1999, the industry saw the publication of SOAP. Originally developed by Microsoft and DevelopMentor, and then passed to W3C for standardization, SOAP used XML as the on-the-wire encoding for remote procedure calls.
SOAP had serious technical shortcomings, but, as a market strategy, it was a masterstroke. It caused further fragmentation as numerous vendors clambered for a share of the pie and moved their efforts away from CORBA and toward the burgeoning Web services market. For customers, this added more uncertainty about CORBA's viability and, in many cases, prompted them to put investment in the technology on hold.
El colapso de la burbuja de Internet, produjo un efecto mortal en CORBA:
The industry's financial collapse drove many software companies out of the market and forced the survivors to refocus their efforts. The result was significant attrition in the number of commercial CORBA products. Before the collapse, several vendors had already dropped or deemphasized their CORBA products and, after the collapse, more followed.
Y lo más importante, las reflexiones de Henning sobre el estándar:
Technical excellence is not a sufficient prerequisite for success but, in the long term, it is a necessary prerequisite. No matter how much industry hype might be pushing it, if a technology has serious technical shortcomings, it will eventually be abandoned. This is where we can find the main reasons for CORBA's failure.
Henning puntualiza los problemas de CORBA:
Complejidad (en el desarrollo de las APIs, en el uso del lenguaje C++, complejidad de tipos usados, especificaciones innecesarias)
Falta de servicios disponibles, Seguridad, Versionamiento, los puntos especialmente señalados:
CORBA's unencrypted traffic is subject to eavesdropping and man-in-the-middle attacks, and it requires a port to be opened in the corporate firewall for each service. This conflicts with the reality of corporate security policies. (Incidentally, this shortcoming of CORBA was a major factor in the rise of SOAP. Not having to open a port in the corporate firewall and sending everything via port 80 was seen as a major advantage, despite the naïvete of that idea.) The OMG made several attempts at specifying security and firewall traversal for CORBA, but they were abandoned as a result of technical shortcomings and lack of interest from firewall vendors.
(...)
Deployed commercial software requires middleware that allows for gradual upgrades of the software in a backward-compatible way. CORBA does not provide any such versioning mechanism (other than versioning by derivation, which is utterly inadequate). Instead, versioning a CORBA application generally breaks the on-the-wire contract between client and server. This forces all parts of a deployed application to be replaced at once, which is typically infeasible. (This shortcoming of CORBA was another major factor in the rise of SOAP. The supposedly loosely coupled nature of XML was seen as addressing the problem, despite this idea being just as naïve as funneling all communications through port 80.)
La lista de defectos técnicos es más minuciosa, pero no quisiera terminar repitiendo el contenido del artículo, aunque sigo pensando que es mejor esto que perderlos, ya que los textos en Internet suelen ser movidos de ubicación.

Pero Henning destaca otro aspecto del declinamiento de CORBA, que es repetido a través de la corta historia de la construcción de software: la idoneidad o capacidad de la institución promotora del estándar. ¿Evolución a través de la investigación académica? ¿de un consorcio de la industria? ¿de una combinación de empresas, instituciones de educación e investigación? ¿la introducción de nueva tecnología por parte de una empresa?
CORBA contó con el soporte de OMG. Qué critica Henning:

The OMG is an organization that publishes technology based on consensus. In essence, members vote to issue an RFP [Request for proposal]for a specification, member companies submit draft specifications in response, and the members vote on which draft to accept as a standard. In theory, this democratic process is fair and equitable but, in practice, it does not work:

There are no entry qualifications to participate in the standardization process. Some contributors are experts in the field, but, to be blunt, a large number of members barely understand the technology they are voting on. This repeatedly has led to the adoption of specifications with serious technical flaws.

RFPs often call for a technology that is unproven. The OMG membership can be divided into roughly two groups: users of the technology and vendors of the technology. Typically, it is the users who would like to expand CORBA to add a capability that solves a particular problem. These users, in the hope that vendors will respond with a solution to their problem, drive issuance of an RFP. Users, however, usually know little about the internals of a CORBA implementation. At best, this leads to RFPs containing requirements that are difficult to implement or have negative performance impact. At worst, it leads to RFPs that are little more than requests for vendors to perform magic. Instead of standardizing best existing practice, such RFPs attempt to innovate without prior practical experience.

Vendors respond to RFPs even when they have known technical flaws. This may seem surprising. After all, why would a vendor propose a standard for something that is known to suffer technical problems? The reason is that vendors compete with each other for customers and are continuously jostling for position. The promise to respond to an RFP, even when it is clear that it contains serious problems, is sometimes used to gain favor (and, hopefully, contracts) with users.

Vendors have a conflict of interest when it comes to standardization. For vendors, standardization is a two-edged sword. On the one hand, standardization is attractive because it makes it easier to sell the technology. On the other hand, too much standardization is seen as detrimental because vendors want to keep control over the features that distinguish their product from the competition.

Vendors sometimes attempt to block standardization of anything that would require a change to their existing products. This causes features that should be standardized to remain proprietary or to be too vaguely specified to be useful. Some vendors also neglect to distinguish standard features from proprietary ones, so customers stray into implementation-specific territory without warning. As a result, porting a CORBA application to a different vendor's implementation can be surprisingly costly; customers often find themselves locked into a particular product despite all the standardization.

RFPs are often answered by several draft specifications. Instead of choosing one of the competing specifications, a common response of OMG members is to ask the submitters to merge their features into a single specification. This practice is a major cause of CORBA's complexity. By combining features, specifications end up as the kitchen sink of every feature thought of by anyone ever. This not only makes the specifications larger and more complex than necessary, but also tends to introduce inconsistencies: Different features that, in isolation, are perfectly reasonable can subtly interact with each other and cause semantic conflicts.

Major vendors occasionally stall proceedings unless their pet features make it into the merged standard. This causes the technology process to degenerate into political infighting, forces foul compromises, and creates delays. For example, the first attempt at a component model was a victim of such infighting, as was the first attempt at a C++ mapping. Both efforts got bogged down to the point where they had to be abandoned and restarted later.

Estas características pudieran adscribirse a múltiples consorcios. Henning especifica éste para OMG:
The OMG does not require a reference implementation for a specification to be adopted. This practice opens the door to castle-in-the-air specifications. On several occasions the OMG has published standards that turned out to be partly or wholly unimplementable because of serious technical flaws. In other cases, specifications that could be implemented were pragmatically unusable because they imposed unacceptable runtime overhead. Naturally, repeated incidents of this sort are embarassing and do little to boost customer confidence. A requirement for a reference implementation would have forced submitters to implement their proposals and would have avoided many such incidents.
En fin, el análisis de Henning puede verse lateralmente como una historia de CORBA, pero centralmente como una reflexión sobre las intrincadas vías de evolución de la tecnología. Henning dice: "Open source innovation usually is subject to a Darwinian selection process". Sin duda, debemos extender la afirmación al conjunto de procesos de innovación.