Code Generation 2008, faltando dos meses

Probablemente la proxima mención sea para publicar lo que esté disponible de la conferencia. Pero, estando ya consolidado el programa de actividades, y habiendo avanzado en el número de auspiciantes, vale la pena volver a recomendar su seguimiento; y para quien pueda, la participación.
Entre los temas propuestos, un buen número de trabajos sobre DSL (Domain Specific Languages) y DSM (Domain Specific Modeling), con participaciçon especial de miembros de Microsoft (Steve Cook). En general, de los trabajos , me parecen importantes estos:
Mark Dalgarno, MDSD and Software Product Lines - a marriage made in heaven? , porque encara las correlaciones entre diseño por modelo y SPL; Brooke Hamilton, Evangelizing Code Generation: A Case Study of Incremental Adoption , porque trata un caso donde la generaciçon de cçodigo se adopta progresivamente en una empresa; Bernhard Merkle, Modelling Standards: what exists, what's missing and what failed?, porque se enfoca en los problemas; y Chul Hwee Kim, Managing Complexity with Domain Specific Visual Languages, porque aplica DSL a problemas complejos.
Entre los participantes y expositores, Anneke Kleppe, Mark Dalgarno, Steven Kelly, Pedro Molina, Juha-Pekka Tolvanen, y Steve Cook.

Las redes sociales como negocio

Therese Poletti, en Market Watch, se pregunta si la compra de la red Bebo por AOL no revela un alcance más realista de este negocio, contrastándolo con la valuación teórica de Facebook (The $850 million all-cash deal was a huge payday for Bebo and its founders, but at the same time, the deal may have placed a lower valuation of Facebook, the darling of social networks, which got its hefty valuation when Microsoft made its investment of $240 million in the Palo Alto, Calif.-based company, for a 1.6% stake).
Poletti se pregunta si el crecimiento de las redes sociales no es parte de otra burbuja, con empresas sobrevaluadas. Comparando Bebo y Facebook, las distancias en utilización no reflejan sus valuaciones:

That notion of a lower valuation, said Ray Valdes, an analyst with Gartner, is based on imperfect data and a range of estimates that Facebook is anywhere from 2.5 to 7 times the size of Bebo. That data varies from monthly visitors to active users to registered users.

For example, Compete.com said Bebo had four million monthly visitors in February, versus 28 million at Facebook, a ratio of one to seven. But active users, as reported by Bebo, are 22 million and 66 million by Facebook, giving Facebook three times the number of users.

"If all things are proportional, it makes Facebook valued at $2 billion to about $6 billion, depending on what you use as a metric," Valdes said. "You could say that Bebo was undervalued or Facebook was overvalued when it was valued at $15 billion. In any case, there is a valuation gap."

Poletti destaca que parece advertirse, en el caso de Facebook, cierto estancamiento en su utilización; implicando en general un pago excesivo por parte de Microsoft por su pequeña participación en la sociedad:

At the same time, there is also a sense that Microsoft's investment in Facebook was at about the time of a peak of what some are calling a Web 2.0 bubble. With the markets now in turmoil and the economy in a decline, investment in startup companies may start to fall off.

Y, finalmente, se pregunta cuánto puede afectar el trato por Bebo-AOL, a otras redes, dedicadas a ámbitos específicos, en general profesionales, como LinkedIn:

It will be interesting to see how the AOL deal affects the value of other social networking companies, especially privately held LinkedIn, which targets business professionals, and niche players, such as ClubMom

Quizá una burbuja pudiera afectar en primer lugar a las redes sociales, y probablemente no tanto a otras dedicadas a actividades profesionales, académicas o de negocios, donde las ventajas de sus servicios son tangibles.

AS400 a pesar de todo

Publicado por Mark Fontecchio, en The ISeries Blog: la historia del ¿AS400? en un mousepad y una prenda de vestir. Mark lo toma de Cafepress.com, donde aparece una lista de prendas posibles. Con nuevo nombre activado, el AS parece que seguirá llamándose así, más allá de los cambios de marketing:

Ken Jack, a software engineer at trucking software company TMW Systems, has created the T-shirt you see to the right. He has it on his personal CafePress website called iWhatever.

Jack reflects the anguish of many System i users — er, users running i on Power Systems — who have a hard time figuring out what to call the server platform on which they run all their business applications. In a recent story on feedback of the System i/p merger, one user told me that he spent a long time trying to convince everyone in his organization that the server and platform should be called System i and i5/OS, not AS/400, iSeries, or OS/400.

Now that IBM has renamed it again to Power Systems and just “i,” expect some folks to just say forget it and start calling it AS/400 again.

That’s how Jack feels, as is apparent by this T-shirt he’s selling. He’s been selling a similar shirt for a while now, just adding on whenever IBM decides to rename the platform again.

“It’s honestly to the point where if IBM changes the name one more time, I’m going to have to put ‘continued on other side…’ on the front of the T-shirts,” Jack wrote in an email to me. “Just last month somebody bought a shirt that stopped at ‘System i.’ I bet he’s pissed.”

What are they calling it at TMW Systems? Jack said that “everybody at our shop still calls it ‘The 400.’ ‘Power System running i’ is just too much of a mouthful.”

By the way, in addition to buying the T-shirt, you can also buy other merchandise with the logo on it: mousepad, coffee mug, baseball cap, etc.

Bueno, como Plex, que parece que quedará como tal: Obsydian, Cool:Plex, Advantage Plex, Allfusion Plex, CA Plex...

Brad Appleton sobre Software Product Lines

Brad Appleton, que es una autoridad en administración de configuración y versionamiento, ha comenzado a enfocarse en Software Product Lines, con la particularidad de aportar el enfoque de la configuración, que debería ser un punto importante del problema. En el último tiempo ha dedicado al menos dos artículos en su blog:
Software Product-Line Architecture and Product-Families, dedicado a presentar brevemente el tema, pero apuntando al aspecto de la configuración.
Commonality and Variability Management, dedicado a presentar un aspecto central, el manejo de los aspectos comunes y las variaciones, con referencias a algunos papeles que discuten el problema en detalle.
Hoy simplemente quería destacar la participación de Appleton. En otro momento volveremos sobre el tema, como seguramente lo hará él mismo: Unir SPL con SCM es algo que se produce naturalmente.

Argentina: Polo tecnológico en San Luis

Publicado en La Nación, hace pocos días: la provincia de San Luis incrementa su oferta tecnológica, con la colaboración de la Universidad de La Punta. Dentro de la línea de usar la promoción para incrementar la actividad económica en la provincia, nuevas facilidades disponibles:

SAN LUIS.- La Universidad Provincial de La Punta (ULP) inauguró un polo tecnológico de desarrollo de software destinado a la radicación de empresas que explotan servicios informáticos.
Con el objetivo de absorber la mano de obra que se forma académicamente en esa casa de estudios, la propuesta consiste en el arrendamiento de espacios físicos con pago de peaje sobre fibra óptica y descuentos de hasta el 40% en los primeros cuatro años de actividad.
Con una inversión de 7 millones de pesos iniciales, la ULP ofrece a los capitales interesados los beneficios de la ley provincial de creación del Parque Tecnológico, con el reintegro del 10% de la masa salarial contratada los primeros 2 años y de un 5% por dos años más.
Los descuentos se extienden a los costos de arrendamiento de oficinas, reduciendo, en algunos casos, la locación inicial, tasada en 10 dólares por metro cuadrado, a 6 dólares mensuales como único gasto empresarial. Con una superficie de 3264,8 metros cuadrados y capacidad para albergar a 12 empresas, el Parque Tecnológico de La Punta (PILP) cuenta en la actualidad con cinco firmas radicadas que "emplean a 102 jóvenes de aproximadamente 25 años, con un sueldo promedio de 2500 pesos", afirmó la rectora y ministra del Progreso de San Luis, Alicia Bañuelos, que destacó que para fines de 2008 "la universidad planea construir más edificios para el PILP" que amplíen esa oferta.
En la actualidad operan en San Luis Mercado Libre, Indra, Telesoft, Unitech y Vit4b y poseen convenio firmado Accendra Networks, Axxon Solutions, Call Center Superville, Ciliare Sofware, Competir.com, Gevenue Technology e Intercomgi. Durante el acto de inauguración del PILP, que incluyó además el edificio del Rectorado de la ULP y los 37 departamentos de 140 plazas destinados a los alumnos de la Tecnicatura en Desarrollo de Software, los empresarios destacaron el marco jurídico, la formación universitaria y la infraestructura tecnológica de la provincia como los principales factores para decidir su radicación.
Incentivo permanente
En esa oportunidad y tras reconocer que, en un comienzo, la relación con las empresas será "deficitaria", el director del PILP, Cristian Moleker, señaló que "por la ubicación geográfica de la provincia es difícil que las industrias tradicionales se desarrollen sin una política de incentivo permanente".
El funcionario agregó que "en las empresas de software, el 80% del costo corresponde a salarios, contra el 30% de la industria tradicional. Esto se debe -explicó- a que en esta última el 70% se va en transporte y adquisición de materia prima. En cambio, en la industria informática, sólo se va en ese rubro un 20%, por lo tanto, este tipo de empresas generan una actividad de alto valor agregado que impacta directamente en sus recursos humanos, que por lo general son jóvenes".
Para Ricardo Viaggio, director general de Indra, que se propone desarrollar sistemas para exportar a Europa, "San Luis muestra una trayectoria que es lo que busca la empresa para ubicarse en un lugar en el que pueda permanecer en el tiempo". Al igual que Ramón Ortega, de Raona, Daniel Rabinovich, de Mercado Libre, destacó la seguridad jurídica como factor que los anima a invertir en tecnología.

Por Claudia San Martín

Johan den Haan sobre Model Driven Engineering

Johan den Haan es un joven especialista encargado en su empresa (Mendix) de investigación y desarrollo. No recuerdo exactamente si lo encontré a través de la referencia de algún colega, o si fue a través de LinkedIn, donde participa también. El caso es que mantiene un blog sobre arquitectura que recomiendo para todos los que quieran profundizar sobre el diseño y construcción por modelos. Acaba de publicar un artículo que avanza sobre las características de la construcción de modelos ejecutables, que puede ser clarificador para quienes quieran profundizar. En unos días más quizá lo tome en detalle, pero vaya ahora su introducción:

In a previous article about Model-Driven Engineering I've stated that the basic principle of MDE is that "everything is a model". Models and model elements are given a first-class status. The essential change is that models are no longer used only as mere documentation for programmers, but can now directly be used to drive software development. Models are used to define implementations, transformations, aspects of software artefacts, viewpoints on a system, and so on. In this article I define what a model is (taking into account the different usage scenario's for a model) and how models can be defined using metamodels.

The definition of models with metamodels can be seen as a language definition which can be done using a general purpose language or a domain specific language. In most approaches a choice is made between a general purpose or a domain specific language. I think both approaches can be combined using the best from both worlds. I'll show the power of this approach with a process modelling example using BPMN and BPEL to build a domain specific process modelling language which is almost directly executable.

Adopción de Tecnologías de la Información en América Latina

El World Economic Forum publica sus informes de evolución de distintos parámetros de análisis de la economía global. Los informes son amplios y es convenientes verlos relacionados entre sí para obtener una visión más completa; en particular, el dedicado a tecnología de la información muestra un leve retroceso para Latinoamérica. El comentario de América Economía, de donde proviene la información:

Sólo cuatro economías de América Latina y el Caribe se encuentran entre los primeros 50 puestos del Global Information Technology Report, un informe del World Economic Forum que evalúa el impacto de las tecnologías de la información y la comunicación (TIC) en 127 países de todo el mundo.
Chile (34), Barbados (38), Puerto Rico (39) y Jamaica (46) son las economías más conectadas de la región, seguidos por México y Brasil, que descendieron hasta los puestos 58 y 59 respectivamente, señala el reporte, difundido este miércoles.
La mayoría de los países de América Latina van a la cola del ranking, en el siguiente orden: Costa Rica (60), Uruguay (65), Colombia (69), República Dominicana (75), Argentina (77), Guatemala (80), Perú (84), Venezuela (86), Honduras (90), Ecuador (107), Bolivia (111), Nicaragua (116), Surinam (117) y por último Paraguay (120).
“El panorama sobre la preparación de los países para utilizar las TIC de manera eficiente para América Latina y el Caribe es menos positivo que el año anterior”, afirmó Irene Mia, economista senior de la Global Competitiveness Network en el World Economic Forum y una de las editoras del Informe.

La elaboración del índice puede no ser suficientemente rigurosa, pero de todas formas entrega un conjunto de indicadores que dan una aproximación:

Para elaborar el ranking, se construyó el índice de Networked Readiness Index (NRI), que examina el grado de preparación de los países para utilizar las TIC de manera eficiente.
En particular, se abordaron tres dimensiones: el entorno de negocios, reglamentaciones e infraestructura de las TIC en general; la preparación de los tres principales interesados (individuos, empresas y gobiernos) para utilizar y beneficiarse de las TIC, y su nivel real de utilización de la última tecnología de la información y la comunicación que se encuentra disponible.
Para construir el NRI, se utiliza una combinación de datos provenientes de fuentes públicas y los resultados de la Encuesta Ejecutiva de Opinión del World Economic Forum. El informe es generado en colaboración con la escuela internacional de negocios INSEAD.

De las posiciones relativas del ranking, son de interés las primeras, lideradas por Dinamarca, Suecia, Suiza y Estados Unidos, en ese orden. Del mundo iberoamericano, España ocupa el puesto 31, Chile el 34, México el 58, Brasil el 59. Y Argentina, 77.
El informe también ofrece una planilla comparativa entre el correspondiente a este año y el anterior. Se puede ver allí que en general los países nombrados latinoamericanos retrocedieron posiciones: Chile del 31 al 34, Mexico del 49 al 58, Brasil del 53 al 59, y Argentina del 63 al 77.
Es posible examinar en detalle cada uno de los ítems que componen el índice, país por país. En el caso de Argentina, un aspecto destacable es que varios de los aspectos más negativos de su clasificación están relacionados con la actividad gubernamental: número de trámites para comenzar un negocio, 112; efectividad para elaborar leyes, 124; carga de regulaciones gubernamentales para abrir un negocio, 113; eficiencia del marco legal, 121; independencia judicial, 119; etc, etc.
También es posible comparar dos países, lo que puede representar un interesante ejercicio de competitividad. Para aquellos que piensan que nuestros países están atrasados por razones que están fuera de nuestro control, nada más interesante que compararse contra un país pequeño e irrelevante aparentemente, que esté bien ubicado en el ranking. Yo probé Argentina contra Islandia, en aspectos como infraestructura, educación, investigación, disponibilidad para los negocios. Los resultados son una bofetada.

Oportunidad para el outousourcing en Argentina

Pablo Pizarro me hizo notar (gracias a las facilidades de del.icio.us) la existencia de esta nota de BussinesWeek, de gran interés para Argentina y otros países de América Latina. Rachael King escribe sobre un fenómeno que era esperable: en la medida en que la industria del software en India (y otros países precursores del outourcing) se hace estable, sus costos se incrementan. Sumado esto a la creciente caída del valor del dólar, de la generalización de la subida de costos de India (y otros países que están pasando a una nueva fase de su desarrollo), ya las diferencias entre presupuestar en India o hacerlo en América Latina, no son tan grandes para la industria estadounidense (o europea). Sumado a las diferencias horarias, se está creando un mundo de oportunidades.
BusinessWeek sobre los costos indios:

Companies that traditionally rely on India for offshore IT services have been looking for that something beyond India for years, citing such reasons as high employee turnover and unreliable communications. But the search has taken on added urgency recently, especially for U.S. companies, as a weakening dollar has boosted the cost of IT services priced in India's rupee. Over the past five years the dollar has declined about 16% against the rupee. High real estate costs and expectations for tax increases also have diminished India's allure.
As outsourcing to India becomes more expensive, North American companies are more inclined to "nearsource," keeping work in the Western Hemisphere, where they can operate in a closer time zone. In years past a company could save 40% to 50% by hiring Indian firms to handle IT and other services, says Atul Vashistha, chairman at neoIT, a management consulting firm. Should the U.S. dollar continue its descent, that differential would shrink to 10% to 20%, he estimates. "If you're only going to have a 20% savings, clients start to think about time zone," Vashistha says.
(...) How much longer the world's companies will have financial incentive to outsource to India is a matter of lively debate. India's "advantage as an offshore location is fast eroding—its attractiveness takes a hit with each passing day," analysts at Forrester Research (FORR) wrote in a January, 2008, report. Forrester catalogued some of the well-known challenges, such as increasing staffing costs, turnover and strained infrastructure (BusinessWeek.com, 12/11/06). Yet, there are newer challenges as well, including the falling dollar and expected tax revisions that may increase the cost of relying on outsourcing providers.

Sobre la comparación de costos con América Latina:

Contracts are written in dollars, and as much as 60% to 80% of Indian service providers' revenue is in U.S. dollars, but more than half of their costs are incurred in rupees, according to an October report from Forrester. Indian outsourcing powerhouses like Wipro are feeling the squeeze. They've strived to cut costs, and now they're raising prices to keep margins from narrowing further. "We are relentlessly driving for higher pricing for our services and have seen price increases from our customers in the range of 3% to 6%, and our new customers are coming in at around 5% higher than our average," Wipro Chairman Azim Premji said on a conference call with investors on Jan. 18.
Duke University professor Arie Lewin estimates that the benefit of doing business, from a labor-cost point of view, in such locales as Bangalore, India, will disappear for some companies in three to four years. That's due to a combination of dollar depreciation, wage inflation, and other costs. Others say it will take longer. "Costs are escalating, so the level of labor arbitrage isn't as great as it used to be, but that's not to say labor arbitrage is disappearing, nor will it disappear in the next 10 years or so," says Sid Pai, partner and managing director of TPI India, a sourcing advisory firm.
Indeed, while costs are increasing in India, the country is generally less expensive than Latin America and most other locations, especially for companies that don't require high-end software developers. The average annual salary for an IT worker in the U.S. is about $75,000, according to a late 2007 report by Alsbridge, an outsourcing consulting firm. In India it's about $7,779 and in Argentina, it's slightly higher at $9,478. In Brazil, the annual wage jumps to $13,163, and in Mexico it climbs to $17,899. "The bottom line is that there aren't great alternatives with the scale, quality, price structure, and the lack of risk of India," says Stephanie Moore, vice-president at Forrester.

Sobre Argentina:

Kimberly-Clark (KMB) had time zone in mind when it hired Cognizant Technology Solutions in Buenos Aires to handle tech support for its SAP (SAP) software applications.
Kimberly-Clark was drawn by the available talent and the fact that the company has Argentine operations but also because geographical proximity and similar time zones make collaboration easier. "We picked Buenos Aires for a number of reasons, but we really felt from supporting SAP, it was the right place to be," says Kimberly-Clark Chief Information Officer Ramon Baez. The company also outsources application development and maintenance to Cognizant in Chennai, India.

BusinessWeek enfoca a México, Argentina, Brasil (especialmente) como posibles receptores de outsourcing en estas nuevas condiciones. Y queda claro que los competidores indios son promotores de este cambio, señalando a Cognizant, Tata, Wipro, e Infosys, como empresas de ese orígen que están activando la ventaja de la diferencia horaria, costo y calidad de recursos.
King de todas formas apunta que la escala de Latinoamérica está lejos de las posibilidades de India, particularmente. La oferta de desarrolladores (u otras áreas de outsourcing) será siempre menor a la esperable en India. Pero la oportunidad existe, particularmente en la medida que se puedan ocupar nichos de especialidad y mayor valor.

El desarrollo de software es un arte?

Rodrigo Corral ha publicado en su blog una entrada sobre la idea del software "al modo industrial" que se explica desde su nombre: "La falacia de la industrialización del desarrollo de software ".
Más de una vez aquí se ha hablado de este tema: en realidad forma parte de la temática de éste blog, y no hace mucho se ha escrito sobre ésto. Como en muchos puntos lo veo de forma muy distinta, creo que debería dedicarle algunas líneas, a modo de extensión de lo que dejé en su entrada como comentario.
En primer lugar, creo que Rodrigo escribe pensando en la industria del software, en empresas específicas, y en políticas comerciales y de recursos humanos. Es probable que en este terreno tenga razones para sus afirmaciones sobre la necesidad de reconocer el valor de cada desarrollador.
Pero no comparto que se extienda el cuestionamiento al propósito de establecer criterios que normalicen el proceso de construcción. Si aceptamos que existe una ingeniería de software, se debe aceptar también que sus intenciones son reducir el riesgo y la incertidumbre en la construcción de software, establecer procedimientos, medir y proyectar, utilizar patrones repetibles.
Por supuesto, el desarrollador tiene importancia. Pero un equipo, y un plan de construcción, no pueden depender de las individualidades: desde hace mucho, reducir la indeterminación ha sido una preocupación generalizada, ante la evidencia de que sin criterios claros de manejo del proceso, un proyecto puede convertirse en interminable, o mucho peor, terminar dramáticamente sin lograr sus objetivos. La historia de la industria está plagada de estos casos. Además, el software debe ser mantenible: no basta crear un software por única vez, sino que debe sostenerse en el tiempo: si dependieramos de las individualidades, cada vez que se produjera una baja del equipo de trabajo, la situación sería calamitosa.
A diferencia de lo que Rodrigo mencionara, como bien se puede ver aquí, creo en la positividad de todas aquellas líneas de investigación que tienden a asegurar procesos más confiables, sea en la utilización de procesos repetibles de manejo del ambiente de construcción (Administración de cambios, seguimiento de defectos, manejo de configuración), como en las herramientas mismas de modelado y generación (generadores de código).
No creo que ninguno de esos elementos vayan en perjuicio del desarrollador, del recurso humano, sino que proponen una actividad más creativa, particularmente en el caso de las nuevas generaciones de 4GL, que permiten poner el acento en el modelado, en lugar del "picado de código".
Quizá la línea de investigación de Líneas de Producto Software sea el ejemplo más generalizador y demostrativo de qué es lo importante del "sofware como industria": SPL propone el planeamiento anticipado, la utilización de patrones, el reuso de partes, la existencia de un repositorio de componentes, la utilización de herramientas de generación de código.
Finalmente, quiero hacer notar que una vía artesana de trabajo, considerando el volúmen que adquiere la intervención de la informática en la economía y la sociedad, si fuera realmente el paradigma aplicado, haría que un alto porcentaje de desarrollos corrieran totalmente por detrás de su necesidad.
En fin, repitiendo lo que le escribía a Rodrigo, "no me gusta la idea de que la construcción de software es un arte, y el programador, un artista. Reconozco que en su construcción hay lugar para la creación y para la belleza (de un algoritmo o de una solución de arquitectura), y que forma parte de la motivación, pero también a esa disposición se la puede calificar con otros nombres, más cercanos a la ingeniería. No me opongo a su existencia, y es excelente trabajar con colegas que den soluciones brillantes; pero no creo que sea conveniente basar una estructura persistente en individualidades, porque dependeremos de ellos. El software debe ser mantenible, y debe tener tiempos de construcción estimables, o al menos planeables. La metáfora de la fábrica siempre la interpreté en ese sentido, y estoy seguro que todos aquellos que han rondado esta idea, lo han hecho en la misma dirección".
Estoy seguro sin embargo, de que la diferencia con sus afirmaciones se reducen a un matíz, que sin embargo quizá sea de importancia.

Discusión sobre la adopción del desarrollo guiado por modelos

En el grupo MDA-Discussion de Yahoo, existe un interesante debate sobre las posibilidades de adoptar el desarrollo orientado por modelos en la construcción de software. Como en muchas oportunidades, el tema dió motivo a un buen intercambio de ideas que abarcan también otros elementos del problema. Dos o tres puntos son destacables.
El hilo nace con una consulta de Arnel Periquet al grupo, cuestionando tres aspectos:

• Modelos ejecutables: ¿tiene sentido formalizar un modelo completo, cuando los desarrolladores pueden manejarse con bosquejos parciales, luego de comprender el modelo general "mentalmente"?
  
• Generación de código: generar código al inicio es posible, pero ¿es posible realmente manejar los problemas de mantenimiento?
  
• Exploración del diseño (o análisis del modelo): el análisis del modelo es una tarea colaborativa, donde intervienen distintas partes ¿puede MDA manejar este trabajo colaborativo?

En palabras de Arnel:

Model execution is useful for understanding domain element interactions abstractly, e.g. how file formats, decoders, cameras and audio/video renderers typically interact in multi-media systems.
After developers learn the domain, they map the implementation to it mentally while stepping through code. If more formalization is needed, UML diagrams are formalized and their system constraints are tracked. The process relies on developer experience and communication. Albeit, turnover of developers experienced with the code base and non-conformance to system constraints and architecture can cause problems. On the whole, however, process checks exist to keep rapidly changing constraints and general maintenance violations in check. - It seems like domain knowledge isn't so much the advantage of automation, as is the mapping knowledge from domain concepts to how they are commonly implemented and maintained. It
would be nice if the models "teach us" the mapping as well as the domain, but marks seems to hide the former. Is this a valid concern and how is it addressed?

Code generation that takes 5 minutes versus 3 days of manual coding is an advantage of only fixed cost. The real cost is in program maintenance. - How does the MDA address maintenance concernces, I mean, other than re-generation? Are there techniques for exposing design actions that map to program manipulation?

Finally, exploring design alternatives with models instead of code is a seemingly decided advantage with MDD. However, design exploration is often a collaborative process involving mutiple experts and stakeholders, e.g. product manager, project managers, architects, designers and testers. The input from various levels should be staged according to adopted process, e.g. agile. This could provide one explanation of the use of whiteboarding and conference calls over the adoption of MDD tools at the system architecture level. - Do MDA
tools directly address collaboration?

La respuesta de H.S.Lahman (Pathfinder) , sobre el primer punto:

One problem here is that stepping through the code is employing a representation that is an order of magnitude less compact that an OOA/D model. In addition, the code addresses many different concerns at the same time (e.g., both functional and nonfunctional requirements
resolution is mixed together by the time one gets to OOP). But the big problem is the level of abstraction. The advantage of dealing with the design in an OOA/D model is that one is not distracted by the details of implementation like language vagaries, particular technologies (SOAP, CORBA, etc.), and techniques (collection class libraries, refactoring to reduce the physical coupling of 3GLs). Those details constitute most ofthe order of magnitude difference in compaction.

I would also point out that an OOA/D model is supposed to be a complete, precise, and unambiguous specification of what the software implementation must do. So there shouldn't be a need for more formalization and the models aren't teaching anything because they /are/
the solution. It is that rigor that allows model level simulation to validate that the design has satisfied the functional requirements prior to committing to code.

Bottom line: I think the point of MDD is that one doesn't have to step through the code to figure out what it is doing or to validate its correctness with respect to functional requirements. IOW, the big gain is not dealing with 3GL code. [As a translationist, I doubt I have written 10 KLOC of 3GL code in total since 1990. I also regard a 3GL debugger like MS VC/C++ pretty much the same way a C/C++ programmer regards an assembly debugger -- life is simply too short for that.]

Sobre el segundo punto:

I would have to argue that the main advantage of MDD code generation is that one /can/ re-generate the code rather than mucking with it at the 3GL level. That ensures that the OOA/D models are always in synch with the actual code and it removes the need for worrying about things like maintainability refactoring. [I know one translation vendor who deliberately makes the generated code difficult to read to prevent people from making changes to it rather than the model.]

However, MDA does support round-trip development by providing a semantic framework with meta models so that tool vendors can provide reverse engineering of code changes back into the models. Unfortunately that is inherently limited because design information about Why things were done the way they were is lost by the time one gets to 3GL code. That's because there tends to be a *:* relationship between OOA/D model artifacts and the OOP implementation mechanisms. So working backwards from 3GL code tends to be ambiguous. IOW, reverse engineering provides a model of the code rather than a model of the design.

Sobre el tercer punto, Lahman lo considera ajeno al problema:

I think this is a quite different issue. It is about how one defines requirements. Product managers, end users, and SQA people are not going to be looking at either 3GL code or OOA/D models, so it really doesn't matter how the developers express their solution design.

One thing to note is that UML combined with a compliant abstract action language is a 4GL. IOW, when one is creating an MDD model one is programming in the same sense that 3GL programmers do; it is just at a higher level of abstraction and resolving nonfunctional requirements has been delegated to a different trade union (the transformation engine
tool vendors). That has two important implications here. The first is that one still needs requirements prior to programming and the shop needs a process for defining them and managing changes to them. How formal or informal that process is depends upon the shop's culture, not whether one is programming in a 3GL or 4GL.

The second point is that agile techniques can be applied to 4GL development in much the same way they are applied to OOP development. (There is a paper on the Pathfinder web site that describes how XP's practices map into translation-based MDD development.)

La discusión es más amplia, y puede consultarse libremente en el grupo, a partir de su raíz. En otro momento, otros aspectos.

Plex-XML

Para interesados en Plex: All About Software de Alemania ha comenzado alrededor de un año atrás, el desarrollo de patrones y un marco de trabajo para extender Plex con un cliente Web basado en transformaciones XSLT. La empresa alemana abrió una wiki que utiliza para difundir el proyecto.
Presentado en la reunión de usuarios en Cincinatti, este nuevo emprendimiento amplía la serie de esfuerzos convergentes para implantarlo en las tecnologías web. Se agrega a los patrones ampliados de Websydian, y a la oferta también presentada allí, del generador web de ADC Austin.
Pueden consultarse las presentaciones de todos los nuevos productos en la wiki de Plex.

Yahoo, Microsoft y China, parte 2

Anteriormente se ha apuntado aquí el factor chino en Yahoo. Hoy New York Times vuelve sobre el tema, a propósito del próximo lanzamiento de una nueva ley antimonopólica que China estaría a punto de presentar. La ley podría poner serias trabas a la compra, ya que autorizaría a examinar compras de empresas en tanto involucraran a compañias chinas. Y ya se ha dicho que Yahoo posee alrededor del 40% del portal Alibaba.com.
Dice New York Times:

Microsoft’s hostile-takeover attempt against Yahoo may encounter an unexpected hurdle in August after a Chinese antimonopoly law takes effect that will extend the nation’s economic influence far beyond its borders.
The law, which goes into effect on Aug. 1, is intended to strengthen an existing set of antitrust regulations the Chinese originally established in 1993. It will make China a third sphere of regulatory influence, matching the power of the European Union and the United States, according to legal specialists in this country and in China who have studied it.
Formally enacted by the National People’s Congress last year, the measure gives Chinese regulators authority to examine foreign mergers when they involve acquisitions of Chinese companies or foreign businesses investing in Chinese companies’ operations. Beijing could also consider national security issues, according to a report by the official news agency Xinhua.
The law could give China influence in Microsoft’s courtship of Yahoo because in August 2005, Yahoo, a premier search portal, invested $1 billion in Alibaba.com, China’s largest e-commerce business. The investment gave Yahoo about a 40 percent stake in the Chinese company. Alibaba officials have said they believe that a Microsoft takeover of Yahoo would set in motion a buyback provision, making it possible for them to gain independence from Microsoft.
Nathan G. Bush, an antitrust law specialist with O’Melveny & Myers in Beijing, said the law represented the ascendance of China “as another regulatory capital contending for influence with Brussels and Washington.”
“Multinational corporations will need to develop strategies for all the markets they operate in,” he added, “and China is a big market.”

NYTimes resalta que la confrontación se haría especialmente dura por las implicaciones sobre la seguridad nacional que Estados Unidos ha argumentado en algunos intentos de compras por parte de compañias chinas dentro del territorio norteamericano.

In the case of the proposed Microsoft-Yahoo transaction, the Chinese have in recent years become more and more alert to the role the Internet plays in their economic and political affairs.
Last week, a vice minister in the State Council Information Office, which oversees the Internet, said there were 230 million Chinese users of the Internet. He said the Internet sector accounted for 7 percent of the country’s gross domestic product, and he expected that to rise to 15 percent in three to four years, according to a Reuters report.
The official, Cai Mingzhao, warned that foreigners should not use the Internet to interfere in Chinese internal matters, according to a report in The Guardian.

En resumen, no sólo se deberá vencer las resistencias en el directorio de Yahoo, sino las impugnaciones asiáticas, que quizá no sean las únicas.

Federico Sánchez sobre la Web 2.0

Recibido a través de América Economía: una visión de la Web 2.0 para principiantes, escrita por Federico Sánchez. No conocía la actividad de Sánchez; ahora está sindicado, con mucho para leer...
De la "guía para empresarios que apenas encienden la PC", algunos aspectos destacados:

Alojamiento y administración centralizada o descentralizada:

(...) la Web 2.0 han mostrado últimamente dos tendencias: localización y descentralización. Ambas tendencias apuntan a aumentar el número de usuarios de las aplicaciones y servicios de la Web 2.0.
La localización va más allá de la mera traducción de la aplicación (internacionalización) e involucra la incorporación por parte de las aplicaciones y servicios ofrecidos (en realidad, en estos casos, el servicio ofrecido es la posibilidad de uso de la aplicación) de características relacionadas con especificidades culturales e idiosincráticas de distintos países y/o regiones (supra o subnacionales). Por ejemplo, MySpace ha desarrollado MySpace España y Myspace México. Es decir, el núcleo de la aplicación sigue siendo el mismo pero se ha traducido la aplicación al castellano y se han incorporado características locales al servicio.
Las aplicaciones y servicios más conocidos (Delicious, Flickr, Youtube, Digg y Linkedin, sólo por mencionar unos pocos) se encuentran administrados de manera centralizada. Es decir, para poder usar dichos servicios, uno debe solicitar una cuenta personal y la información que vayamos guardando (y compartiendo) se encuentran alojados en el servidor del proveedor de la aplicación. En muchos casos, ésto guarda relación con el modelo de negocio de muchas aplicaciones de este tipo: el desarrollador pretende monetizar la aplicación mediante la inserción de publicidad contextual o, venderlo a alguna empresa más grande, preferentemente a GYM (acrónimo de Google, Yahoo, Microsoft). En todos los casos, el éxito del negocio se sustenta en un número elevado de visitas y usuarios.
Sin embargo, existen alternativas a esas aplicaciones que pueden ser administradas de manera descentralizada y el desarrollador (o alguien más) presta un servicio que consiste en la conformación de una “red distribuida” sobre la base del conjunto de aplicaciones descentralizadas.
Por ejemplo, Sabrosus es la versión descentralizada o “distribuida” de Delicious (un agregador de marcadores sociales). En Delicious, previo registro como usuario, cualquiera puede guardar enlaces clasificándolos por medio de etiquetas (tags). Sabrosus, luego de descargarlo e instalarlo, nos permite hacer exactamente lo mismo, pero la información se encuentra en nuestro servidor. Sopa Sabrosa se encarga de agregar las etiquetas con que han sido clasificados cada uno de los enlaces guardados.
La alternativa descentralizada es particularmente importante en el caso de las empresas como potenciales usuarios de este tipo de aplicaciones. Las firmas, con o sin razón, son particularmente celosas en el manejo de aquella información que podría ser calificada como “sensible” o “confidencial”. Otro ejemplo: Basecamp es una aplicación orientada a la gestión de proyectos y el trabajo colaborativo. Sin embargo, alguien notó que, aunque el costo del servicio era muy inferior al de las licencias de programas con funcionalidades similares (lo que en principio era una ventaja), el alojamiento de los datos referentes a proyectos en servidores ajenos a las empresas podría implicar un obstáculo para su adopción por parte de muchas de ellas. Así se inició el desarrollo de activeCollab, un clon de Basecamp.

Gestión del conocimiento y trabajo en colaboración

Las wikis son programas que permiten a sus usuarios crear, modificar y enlazar páginas web. Las wikis son herramientas orientadas a la escritura colaborativa (por ejemplo, la conformación de bases de conocimiento). Según los partidarios de este tipo de herramientas, su uso en las empresas se traduciría en una reducción del envío de mails y la realización de llamados telefónicos y reuniones, entre otras cosas, lo que resultaría en un significativo ahorro en dinero y tiempo.
(...)Un artículo de BusinessWeek da algunos detalles sobre las experiencias de Nokia y Dresdner Kleinwort Wasserstein (DrKW) con relación a la implementación de wikis:

Nokia estimates at least 20% of its 68,000 employees use wiki pages to update schedules and project status, trade ideas, edit files, and so on.

Y en el caso de DrKW:

The initial efforts at Dresdner, for example, confused employees and had to be refined to make the technology easier to use. More important than tweaking the technology was a simple edict from one of the proponents: Don’t send e-mails, use the wiki. Gradually, employees embraced the use of the wiki, seeing how it increased collaboration and reduced time-consuming e-mail traffic.

Stephen Johnston, Senior Manager de Estrategia Corporativa de Nokia plantea que:

Wikis are a very tangible expression of our open way of working […] Now, we can not only talk about openness, we have a tool that is at its core based on collaboration.

Es decir, las wikis no son para cualquier empresa: debe preexistir a su implementación una cultura de colaboración (al menos en una parte de la firma) y los miembros de la organización deben modificar pautas de comportamiento en el trabajo y recorrer la curva de aprendizaje asociada al uso de estas herramientas (en criollo, los resultados no aparecen rápidamente). En el blog de Dutto PR, Leo Piccioli, Gerente General de Officenet, hace un comentario sobre su experiencia al respecto.

Gestión de oportunidades de negocios
Este punto es particularmente discutido por Sánchez, que tiende a considerar no muy alto el valor de las redes profesionales y de emprendimientos y negocios:

(...) El éxito de los negocios en China (o no fracasar) depende, en buena parte, de lo que se conoce como guanxi (关系), una red de contactos cuyos miembros sienten mutua empatía y se prestan asistencia más allá de sus intereses individuales. La sociología ha relacionado el guanxi con el concepto de capital social y Gemeinschaft. En Rusia, sólo por mencionar otro lugar con profundas diferencias culturales con nuestro país, se denomina blat (блат).
En este punto, el potencial de las herramientas de la Web 2.0 está sobrestimado.
Un artículo en The Guardian (ver la traducción publicada en Clarín) sostiene que algunas investigaciones habían planteado que el grupo de amistades de un individuo consta de unas 150 personas, con cinco amigos muy cercanos y un número más amplio de personas con las que nos mantenemos en contacto con menos regularidad. Esta cifra mostró tal constancia que no fueron pocos quienes se animaron a sugerir que la misma se encuentra determinada por las limitaciones cognitivas de prestarle atención a gran cantidad de gente.
Sin embargo, un reciente estudio presentado en el British Association Festival of Science 2007 realizado por la Universidad de Sheffield Hallam mostró que los sitios de redes sociales permiten ampliar esa cifra.
Pero, William Reader, investigador a cargo del estudio, sostiene que:

La gente considera al contacto cara a cara como algo absolutamente imperativo para establecer una amistad íntima.

Los sitios de redes sociales permiten a la gente ampliar su lista de conocidos porque el hecho de mantenerse online es sencillo:

Reducen el costo del mantenimiento y creación de estas redes sociales porque se puede enviar información a muchas personas.

Y según el mismo Reader, para establecer una amistad real:

[…] necesitamos estar absolutamente seguros de que el otro va a invertir realmente en nosotros y estará ahí cuando lo necesitemos. En Internet es muy fácil mentir.

Aunque hay argumentos a favor y en contra sobre la capacidad de las herramientas de la Web 2.0 de aumentar el guanxi de los empresarios, podría al menos afirmarse que sí permiten elevar la productividad del trabajo que conlleva el mantenimiento de dichas relaciones.

La guía de Federico Sánchez es más extensa. Recomendable de leer y seguir.

Software en Argentina: ¿Qué modelo de industria es deseable?

Ya que se acaba de mencionar el salto de la industria del software en Argentina, es más que oportuno recordar las reflexiones de Oscar Bianchi, gerente de una empresa de desarrollo en Rosario, publicadas en Infobae Profesional en enero de este año.
Sus observaciones están dirigidas al mercado y posibilidades de las pequeñas y medianas empresas dedicadas al software; en primer lugar, pensando en cómo la aparición del negocio de los grandes competidores pesa en su mercado, pero indirectamente, aplicables más extensamente al modelo que pueda ser más conveniente para Argentina.
En pocas palabras, su idea es basarse en la oferta de producto software. Secundariamente, Bianchi discute y cuestiona también la concepción de venta de horas de adaptación y ajuste a las necesidades de un cliente, como negocio rentable. Extendiéndolo más, cuestiona el modelo adoptado de venta de recursos humanos en lugar de producto:

“Único e irrepetible” es uno de los mitos de la producción de soft. En un extremo está Ford diciendo que venderá autos de colores, siempre que sean negros. En el otro está su empresa: “A cada cliente un producto”.
Un estudio reciente del Polo Tecnológico de Rosario demuestra que Argentina, en un error estratégico, ofrece recursos humanos técnicos a la globalizada industria del software. Este rol muy bien puede realizarlo China o India, con su interminable población, pero no Argentina. Se potencia esta situación con la llegada de mega-compañías que se instalan en nuestro país y convocan a cientos de especialistas, encareciendo enormemente los costos de las Pymes. Lejos de lamentarnos por este desacierto cuando no está en nuestras manos cambiarlo, sí tenemos la obligación de reconocerlo. El personal técnico es escaso y caro. Entonces, ¡no hagamos descansar sobre ellos el peso de nuestra expansión!
El camino a seguir es cerrar productos y desarrollar… el área comercial. El personal comercial es más fácil de conseguir e impacta menos en el costo, ya que el grueso de sus ingresos proviene de sus ventas. En lugar invertir materia gris en adaptar un desarrollo al interminable deseo de un cliente, debemos concentrar inteligencia en concluir un proceso y reflejarlo en el producto final. Luego, desplegar recursos de otras áreas para el cierre comercial del producto:

• Diseñadores gráficos (packaging, logos, carpetas, diseño web)
• Licenciados en comunicación (manuales de uso, contenidos web)
• Marketing y vendedores (comercialización)

A partir de ahí, el área comercial debe hacer coincidir esa solución con un nicho de mercado y venderlo cuantas veces pueda. Si pensamos en términos de los negocios tradicionales de venta de mercadería, cada vez que cerramos un producto de software estamos stockeando a tope nuestro depósito, ya que puede replicarse tantas veces como compradores hallemos. Oriente no sólo se destaca por las estatuillas de barro, también son origen del just in time, fabulosa promesa de reducción de costos que obliga a reordenar completamente a las organizaciones. Ese resultado prometido que buscó, por ejemplo, Toyota a través de un enorme empeño; usted puede alcanzarlo sólo con enfocarse en el cierre de productos. Mágicamente se habrá convertido en una empresa que no realiza mayores esfuerzos para hacer llegar en tiempo y forma la solución a su comprador. Y lo que es mejor, ¡sin costos de logística y almacenaje!
La bonanza económica de la región nos hace pensar que al vender desarrollo hacemos un buen trabajo, y mal muestra una debilidad como fortaleza, porque ¿qué pasará cuando la demanda caiga y ya no golpeen a nuestra puerta? Nuestros desarrollos interminables, cada uno de ellos únicos e irrepetibles, podrán apenas pervivir en la empresa de sus compradores, que serán los nuevos directores de nuestras empresas.
Muchos empresarios buscan inversores para que internacionalicen su empresa e intentan vender el know how de una herramienta de desarrollo aplicada a un tipo de negocio. Creen ser dueños de una torre y están parados sobre un montículo de tierra.
La estrategia de soluciones cerradas, además de multiplicar los prospects por la proactiva acción comercial, nos permite llegar a mercados externos con pocas adaptaciones. Esto es lo que verdaderamente interesa a un inversor. Y aunque no recibamos el ansiado apalancamiento externo, estaremos creando una red de contención que atenúe el impacto de una posible crisis regional.

En resumen, un producto cerrado es:

• Una ventaja competitiva
• Un depósito lleno de mercadería
• Una posibilidad permanente de venta
• Una potencialidad de trabajadores técnicos disponibles
• Un seguro contra las crisis cíclicas

Referencias a las actividades de Chess, su empresa, en TICS (consúltelas mientras estén en línea).

Cognizant en Buenos Aires

Clarín comenta el 15 de marzo, a propósito de la inauguración de oficinas de Cognizant en Buenos Aires, la creciente actividad de exportación de software en Argentina.

La industria del software venía cocinando a fuego lento su potencial exportador y explotó a partir de 2002, con la radicación de call centers y "fábricas de software" de multinacionales como Motorola, IBM, Oracle, Google y Hewlett Packard. Se estima que el año pasado la facturación del sector rozó los US$ 5.500 millones, con exportaciones por US$ 400 millones.

Clarín puntualiza una de las razones de esta explosión, comentada en la inauguración de Cognizant:
La radicación "cuenta con incentivos fiscales a la exportación de software, a través del régimen vigente hasta marzo de 2009". Tanto la incentivación vinculada a la reciente ley de promoción del software, como la favorable relación de costos posterior a la crisis de 2001/2003, están en la base de este crecimiento.
Sobre la nueva empresa localizada, Clarín resume:

Llegaron tímidamente a la Argentina hace un año, como proveedores tecnológicos para la filial local de Kimberley Clark, la dueña de los pañales Huggies. Pero en poco tiempo fueron armando desde aquí una base de negocios lo suficientemente sólida como para abrir su propia filial. Cognizant, si bien tiene su sede en EE.UU. y cotiza en el Nasdaq, es sobre todo una de las grandes empresas de software de la India, especializada en proveer soluciones informáticas para la administración de las corporaciones. Y ahora utilizará su nuevo cuartel central de la Capital para ofrecer soporte a clientes de todo el mundo, pero en especial a los de Estados Unidos, país con el cual Argentina tiene un huso horario similar.
En su nuevo centro de desarrollo porteño ya hay trabajando 70 programadores de software, que llegarán a ser 250 hacia fin de año, según adelantó Francisco D'Souza, presidente y director ejecutivo a nivel mundial de Cognizant, quien inauguró el edificio de la filial junto al Jefe de Gobierno porteño, Mauricio Macri.
"Es un gran momento para estar en la Argentina, donde las exportaciones de tecnología son crecientes", dijo D'Souza. "Al ser una empresa cuyas operaciones provienen de la India, esperamos también formar parte de las crecientes relaciones entre ambos países", agregó.

Factoría de Software no es solo outsourcing

Este comentario está motivado por las reflexiones de Mancarf, que conocí a propósito de un comentario suyo en otra entrada anterior, no del todo relacionada con lo que vamos a conversar. Tratando de conocer a quien efectuara un comentario a una entrada mía sobre factorías de software, entré a sus propias ideas sobre este tema. Manuel pone el acento, hasta donde leí (me falta completar la lectura), en la relación entre las factorías y el outsourcing. Más de una vez me pareció que era necesario aclarar este punto, que creo que está confuso. Aunque mejor es decir que se trata de una ambiguedad; Que el outsourcing se base en general en la idea de factorías, es una consecuencia. Estoy seguro que Manuel comparte este punto de vista también...

La idea básica que está detrás de la factoría, es la de construír el software de una manera análoga a como se construye un producto en la industria. Las empresas de manufacturas tiene una larga y madura experiencia en cómo producir, partiendo de patrones comunes, elaborando kits de componentes, reutilizando partes, estandarizándolas para que un proveedor pueda entregarlas, definiendo mediciones de tiempos, entre muchas técnicas; y ésto tanto en la fase de diseño y planificación de una nueva línea, como en la producción en masa del producto definido. Y lo mismo sucede con los proyectos de ingeniería que aplican procedimientos y componentes bien definidos, para generar un producto cuasi único, tal como un puente, un edificio, un barco.
Así, cuando los precursores hablaron de fábricas de software, pensaban en estas similitudes: en la mejora de cada aspecto de la construcción de software, para lograr procesos repetibles, medibles, usando componentes o patrones reutilizables, de tal forma que el proceso sea confiable, y económico. En su primera época, el interés estaba enfocado en el desarrollo propio, en grandes empresas o instituciones. Sólo ha evolucionado hacia una cercanía con el outsourcing en años más o menos recientes, en la medida que India, Irlanda, Brasil, Europa del Este y otros, pudieron convertir el diferencial de costo en un negocio conveniente.

¿Cómo veo a las factorías de software?: En efecto, como un requisito para ofrecer outsourcing; esto puede ser un buen negocio para algunos países, o dentro de un país, aprovechando nichos de mercado. Y aquí coincido con Manuel en cuanto a los límites que este esquema puede tener.
Pero el software como construcción industrial, como factoría, es una idea más general, y es en ese terreno en el que realmente me interesa. A condición de que un emprendimiento sea del porte adecuado, tanto por tamaño, como por su perdurabilidad, probablemente la generalidad de los proyectos podrían y deberían afrontarse utilizando prácticas y recursos típicos de una factoría.
Considero que en estos casos, las investigaciones sobre Lineas de Producto Software (SPL), así como las investigaciones sobre desarrollo basado en modelos (MDD), deberían ser una fuente de recursos a ser revisada y adoptada. Dados los auxiliares metodológicos, recursos y herramientas que hoy existen desarrollados, no es viable desconocerlos y omitirlos.

Nota: He mencionado la excelente y breve descripción que hace el ESI sobre MDD, que, siendo parte de su página de presentación, tiene el riesgo de estar disponible para leer ahora, pero no dentro de un año o dos. En previsión, un pequeño resúmen existe en estas páginas.
Sobre SPL, MDD, DSM y DSL, mucho se ha apuntado aquí. Solo es cuestión de buscar.

Microsoft notifica a sus empleados sobre el impacto de la absorción

El mérito es de Martín Pérez: publica su visión de la circular interna remitida por Microsoft (no tan interna, al ser publicada en su sitio) para comunicar a sus empleados el alcance de una eventual absorción de Yahoo. Creo que puedo compartir sus opiniones, incluyendo el hecho de que representa la visión "pour la galerie". Dice Martín:

• ¿Cuáles son los beneficios de una combinación Microsoft-Yahoo!? Aunque no lo dice en ninguna de las tres razones que aporta (mejor R&D, estimular el mercado de la publicidad online, y ventajas para los accionistas) está bastante claro que el transfondo es competir con Google.


• ¿Habrá reducciones de plantilla? Sí, en ambos bandos.


• ¿Qué pasa con las culturas de ambas compañías? La idea será combinarlas y quedarse con lo mejor de cada una.


• ¿Qué pasará con las marcas y las tecnologías de cada compañía? La marca de Yahoo! se queda, ya que es una de las razones de la compra. Poco a poco se vería como se integra con las marcas de Microsoft.


• ¿Qué pasa con la infraestructura de Yahoo! basada en Linux? Se mantendría como está y se procedería a un plan de integración entre ambas plataformas. El correo deja la puerta abierta a la migración de estos servicios a Windows.


• ¿Se mantienen los centros de Silicon Valley y Redmond? Sí.

¿Puede ser una hipotética absorción una victoria pirrica? Hace tiempo que el estilo de gerenciamiento de Microsoft (me) dá la impresión de ser errático e ineficiente, disimulado por el inmenso alcance de la compañía. ¿Puede manejar la integración de otra gran empresa? ¿Puede conservar los activos de Yahoo?

Yahoo-Microsoft desde la perspectiva china

Como la carta de Yang a sus accionistas lo hace notar, la posición china de la empresa es un fuerte apoyo a su confianza en la salud futura de su negocio, suficiente para decir no a la oferta, y capaz de ahondar las distancias entre Yahoo y Microsoft. Hoy dos medios económicos ponen el acento en el alcance de los intereses chinos de Yahoo: AliBaba, más Yahoo Japón, valen 13.800 millones de dólares, y se valorizarán alrededor de un 15% más durante 2008. A éste valor de mercado, El Economista de España le agrega otro que no debe subestimarse: quizá al gobierno chino no le interese que una empresa china de importancia, quede bajo control monopólico. La nota de Clarín:

La presencia de Yahoo en los crecientes mercados de Internet en China y Japón supone un tercio del valor de lo que el gigante informático, Microsoft, ofreció por la compañía, informó hoy el diario local "Shanghai Daily".
Yahoo cuenta con una participación destacada en Alibaba.com, líder en comercio electrónico en China, y en el portal nipón Yahoo Japan.
Yahoo rechazó la semana pasada una oferta de compra por parte de Microsoft por valor de 44.600 millones de dólares (30.390 millones de euros), al considerar que esa cifra "infravalora considerablemente" a la compańía, pues no tenía en cuenta el valor de la marca, su audiencia mundial y sus perspectivas de crecimiento.
Sólo sus acciones en Alibaba.com y Yahoo Japan valen conjuntamente 13.800 millones de dólares (9.400 millones de euros), según el diario chino.
Los analistas locales del sector calculan que ambas participaciones podrían revalorizarse sólo durante 2008 en un 15 por ciento, hasta los 15.900 millones de dólares (10.830 millones de euros).
De hecho, el presidente de Yahoo, Jerry Yang, indicó durante su rechazo del intento de compra de Microsoft, que sus inversiones en Alibaba y Yahoo Japan son parte de las razones por las que considera la oferta tan infravalorada.

Y el comentario de El Economista:

La mayor compañía de comercio electrónico de China, buscará que la voz de su equipo directivo resuene con más fuerza en la posible venta de Yahoo! a Microsoft. Y es que Yahoo! controla el 39% de las acciones de la compañía china. El problema es que las autoridades de Pekín perciben que una importante empresa china podría caer bajo el control de Microsoft, siempre bajo sospecha de monopolio.

Sobre AliBaba, en El Economista:

Alibaba tiene ahora mismo una capitalización de 25.700 millones de dólares [noviembre de 2007, época de su lanzamiento en bolsa], la segunda compañía de Internet más grande de Asia tras Yahoo! Japón.
(...)Para los inversores, el gran atractivo de Alibaba no es sólo que ha sabido desembarcar en Internet el poderío productor de la llamada fábrica del mundo, creando un gran mercado virtual que pone en contacto a empresas productoras chinas con compradores chinos y extranjeros. Su potencial, estiman, es que existen en el gigante asiático 42 millones de pymes y 162 millones de usuarios de Internet.
Al tiempo, la tendencia del negocio es inequívoca: sus ingresos han pasado de 35,9 millones de euros en 2004 a 136,3 millones en 2006. A semejantes expectativas es menester añadir una variable adicional: hasta la caída de ayer, la bolsa de Hong Kong subía un 57 por ciento en lo que llevamos de año.

Compartiendo intereses

Google Reader amplió el alcance de los ítems compartidos: desde hace algún tiempo (pocas semanas), es posible no sólo presentar en otra página los feeds de interés que el lector destaque, sino que ahora, si los creadores de las entradas leídas son también contactos del lector, sus propias lecturas destacadas aparecen listadas: una manera rápida de compartir intereses con colegas y amigos, a condición de que el seguimiento que los colegas y amigos apunten en el mismo sentido.
De todas formas, más potente sigue siendo para esto del.icio.us, cuya única limitación insalvable sigue siendo la fragilidad de Internet: un enlace vale en tanto el servidor que lo sostenga no cambie el criterio de alojamiento, o peor aún, desaparezca (¿Alguien consiguió establecer un seguimiento seguro de un tema de interés en MSDN, al momento de que su producto cambie de versión?) Quizá en el futuro pueda concertarse un sistema de identificación que deje a salvo las variaciones de ubicación de los sitios, pero por ahora, mi único auxiliar es The Internet Archive, capaz de dar algo de eternidad a lo que se construya en la Red.
De paso, del.icio.us es una de las razones por las que espero que Yahoo no sea comprada.

Integración contínua (Continuous Integration)

Aplicado a Plex, un artículo en curso de elaboración en la wiki toma uno de los puntos de particular interés no sólo en este caso, sino en general en las distintas variantes de generación de código a partir de modelos o directivas de alto nivel. El artículo parte del papel escrito por Martin Fowler sobre Integración Contínua, y examina lo que Plex cubre, y lo que le falta para lograr el objetivo: un equipo de trabajo desarrollando cada uno su parte, e integrándola a un repositorio común, con un proceso definido de resolución de conflictos, compilación, testeo, implementación (Any individual developer's work is only a few hours away from a shared project state and can be integrated back into that state in minutes. Any integration errors are found rapidly and can be fixed rapidly.This contrast isn't the result of an expensive and complex tool. The essence of it lies in the simple practice of everyone on the team integrating frequently, usually daily, against a controlled source code repository).
Las observaciones del autor del artículo (John Bell) apuntan a la necesidad de extender la integración del proceso de construcción de tal forma que sea posible tener control sobre todos los elementos participantes del proceso, y de todos los estados hasta su implementación. Difiero con Bell en cuanto a que es posible tomar más control del proceso partiendo de los recursos que hoy se disponen. Estoy de acuerdo en que este mayor control no está incluído en el producto mismo.
Estos aspectos son los que, en términos generales, hacen interesantes las ideas de Jack Greenfield sobre su Software Factory, más allá de su final concreción. Creo que existen más ideas estimulantes en la descripción genérica de su idea, que en cómo se la ha implementado.
Estaremos esperando el desarrollo ulterior del artículo en la wiki...