Nuevas reflexiones sobre el software futuro

La semana pasada hubo un gran revuelo en la comunidad de usuarios de Silverlight. En su PDC2010 (Professional Developers Conference 2010, finales de octubre), Bob Muglia y Steve Ballmer hicieron comentarios que indujeron a pensar a distintos observadores que Silverlight pasaba a una vía muerta. Mary Jo Foley publicó un artículo que corrió como la pólvora, y desató toda clase de especulaciones que todavía duran. Aunque el tema de por sí es muy interesante, en este caso deberá quedar para otra oportunidad. Está por verse si realmente Siverlight pasa a mejor vida, o el revuelo proviene de un torpe manejo de relaciones públicas (dicho sea de paso, el post del blog de Siverlight que acompañó al anuncio, y que se convirtió en un muro de los lamentos, todavía no ha tenido una respuesta clara y definitiva de parte de sus autores, a cinco días de emitido). En fin, lo que particularmente me atrajo en este caso, fue el tipo de discusión que generó: una vivísima representación del estado de la construcción del software en ésta época. Lo que sigue es una lista de asuntos de primera importancia que fueron discutidos. Todos los comentarios siguientes son respuestas al post de Bob Muglia en el sitio de Silverlight. Al fin de cada párrafo se indica el nom de guerre que cada usuario prefirió usar. Hay mucho más material en otros sitios que generaron respuestas, otros interesados con blog propio, comentarios de periodistas de tecnología, etc. Quizá más adelante se agregue algo de esto.

Múltiples dispositivos y plataformas, no más un ambiente cerrado y confortable
Uno de los temas de mayor preocupación reflejados es el de la cobertura del producto respecto de dispositivos crecientemente heterogéneos, no sólo escritorio: mientras sus seguidores esperarían la ampliación de Silverlight "al menos" a Android, si algo dejan claro, es que para el producto, sólo hay planes para Windows Phone 7. Claramente, el mundo ha devenido heterogéneo y no monoproducto:

I'm in a project where we have to make a decision between Silverlight and HTML5. We were leaning toward Silverlight, but then put the brakes on when we heard about the comments from the PDC. This blog post doesn't help Silverlight's case. It merely looks like you're trying to calm a panic. But the reality is that anyone deciding on Silverlight vs HTML5 for new applications, that will be supported years down the road, must seriously consider jumping into HTML5 as the safer path. Clearly you've admitted it's the best path for cross platform applications. In an iPad, Android, Windows and everything else world we are flying toward... how can we *not* pick HTML5. (Dave Friedel)

To rectify this, I need to see an announcement that Silverlight will be ported to Android. Flash has. Yes, an iPhone port won't happen bc Apple policy, but Android is shipping on more phones and is more likely to be used by business people than iPhone. WP7 is starting from too small a base to invest in significant development. Right now develop for iPhone bc it's got the buzz, Android bc it's got the momentum, and then WP7 if and when resources allow. An Android port of Silverlight means develop for Android/WP7 first which further deflates iPhone momentum. Think strategically. (Anónimo)


I understand that porting it to iPhone is beyond Microsoft's reach and depends primarily on Apple , but it would be nice to get it ported to Android. No one expects you guys to cover all of the platforms with SL, but it would be nice to cover the most popular ones.(Nick Polyak)


Your competitior isn't backing away from taking its technology to popular platforms - they're finding ways to reward developers and designers for their continued support and loyalty by making sure they have a path to run everywhere that's relevant. There's no questioning their commitment, and yet questions persist about yours. (Anónimo)

Basically you're saying that it's not a battle you want to fight, so you're giving up altogether. I don't think everyone expected Silverlight to be on every device. Heck, the top 10 would be more than enough to satisfy nearly everyone out there (including devices your company controls and owns, such as Windows, Zune/WP7 and XBox).
HTML5 certainly hasn't had a problem with adoption on several devices. Heck, even Android (an entire OS) hasn't. So why is Silverlight having such a challenge in doing it? (Daniel)


I've been building a website over the past 2 years that incorporates 20,000+ lines of Silverlight on the client side (and yes, it really does need to be that complex.). I've been completely trusting Microsoft's commitment to this platform, but I'm now very very worried indeed. I've just spent all weekend learning GWT, and I'm starting to think a port might actually be plausible. Bob's blog post really seems nothing more than a half-assed effort at damage control, and I'm afraid that where there's smoke there's probably fire.
This time last week, I was silverlight's greatest fan. But unless you do a *lot* more to restore my confidence, I'm planning to spend the next month seeing how far I can get in migrating to GWT. I can't quite understand why you think this is a good thing for Microsoft. (ArcMan)

I'd like to see Silverlight and the Metro UI phone/tablet interface integrated tightly into Windows 8 the way iOS is being integrated into OSX Lion.

Microsoft should utilize Windows Phone 7 and the Silverlight implementation to create an install base of developers who can then populate a mobile, desktop, tablet, and web app store. It only makes sense then to include license options for apps that run across the different mediums the Silverlight can hit.
I think anyone who doesn't see Silverlight as an LOB/media tool is missing the boat. I would never build a website in Silverlight. I would build my media viewer or my backend system though. I would definitely build an app on Silverlight. (CKLuis)


" As a result, getting a single runtime implementation installed on every potential device is practically impossible. " [conceptos de Bob Muglia en su post]
It's absolutely possible, and moreover that's exactly what must be done. You can have platform specific extensions of course, but core must be the same for all platforms. And if you cannot implement SilverLight runtime for all possible devices, just open source it, and it will be ported to any "potential" device in few months, and we won't need to even listen this meaningless statements how "cool" HTML5 is. (Sipank)

As a .NET/XAML programmer I've been very disappointed that I can't target one of Microsoft's popular platforms, the XBOX 360. It has been difficult to understand this glaring omission, but Scott Barnes' explanation as to the internal unpopularity of WPF sure seemed to make a lot of sense. For the immediate future, say the next five years, these are the relevant platforms...

Windows
Mac
iPhone
Droid
WP7
XBOX
Playstation

You're already on three of the seven. After watching you guys for years supporting NT on x86, Alpha, and x64, you can't convince me that you can't easily port a 5MB runtime to four more platforms. The tools and silverlight groups have done AMAZING work, to "shift" strategies now would truly be grabbing defeat from the jaws of victory. I imagine your partners like Netflix would be delighted if they never had to do another port again and could rely on Silverlight. Seriously, if Sun and their grotesquely incompetent programmers were able to port java to so many platforms, you guys should at least be able to get it on seven. (Jack Bond)

I see silverlight as a better and lighter version of desktop runtime in replacing wpf which is so heavy and hard to deploy to people who don't have the latest runtime.
I found that even without html 5, the current javascript + html4 + css enable people to build much prettier and user friendly UI. Silverlight follows a desktop UI philosophy and doesn't really fit into the browser except some case of advertising oriented banner... (collaboration cloud)

Do what should have been done in the first place - make Silverlight compile down to a html5 compliant web application. You know, sorta like how GWT does it. Write java, get all the benefits of it, but it produces minimized, best practice compiled javascript.

I think MS took the fight against 'Flex', and by the time it was ready, realized they missed the train because Apple and Google are attacking the web pieces, meanwhile MS went backwards and is now sitting in the same 'yucky' spot as Adobe.

Making browser plugin's is yesterday's technology.

Actually, what is odd, is that the MS team used Script# to build the online Office - not Silverlight - that alone should tell you the status of Silverlight. Wake up people. MS should be investing in Script#, not Silverlight. (Steve)


The community will definetly like to see silverlight ported to more platforms. How commited are you to making silverlight cross platform? (Arson)

When you buy a PC or a car, you own it. You are free to use it the way you like and you can install any extension/software you want without asking the manufacturer. The mobile phone market is different. Think of it as a car you paid for in cash, however every year you have to pay a license fee and for every drive you have to pay-per-use for the steering wheel. Not to mention the payment for the manufacturer's OK for 3rd party tires... This is exactly the Apple business model for the iPad/iPhone. You buy it, yet Apple owns it/controls its usage.
Now Microsoft obviously failed in coming up with a similar or competing business model. Option a) entering the hardware market, controlling the devices, with full power offends all hardware partners and option b) controlling the application market through a license check in the SL runtime fails, because Silverlight (legally) cannot be installed at the majority of mobile devices.
(...)

So dear fellow developers, this is not about SL, this is about losing the first big battle on the mobile phone operating theatre. We're the collateral damage.

Microsoft has enough cash for scraping another phone platform; happened early this summer didn't it? However what about you and me?
And I hope: Microsoft buys Nokia. (Hidden War)

Los lenguajes y arquitecturas propietarias son un escollo
Un tema que subyace en la preocupación de varios de los reclamantes, es la necesidad (aceptada o no, da lo mismo en este caso) de adaptarse a estándares concertados, dado que "el mundo es ancho y ajeno":

What we have here is a fundamental conflict between the desire for standards (although how anyone can call HTML a standard is beyond me since even simple stuff renders differently in different browsers) versus the desire for productivity. Given enough time, resources, and patience, you could create and maintain just about any piece of software using just about any environment and tools. However, creating increasingly complex RIAs with the brain dead HTML/CSS/Javascript/4 million libraries stack strains the time constraints and resource that companies have and exceeds the patience of professional developers used to working with even modestly productive development environments. Silverlight should be more correctly call Silverbullet because it massively overdelivers on the productivity and capability needed to create RIAs. If standards are a problem, why not just turn the future definition Silverlight over to a standards body like Netscape did with Javascript and whoever did with HTML? Then the standards people would have their objections undercut and those of us who actually do development could get on with our work. (Bryan Morris)


Perhaps MS should consider releasing a lightweight SL runtime for low power handheld devices. This make great sense, because these small screen interfaces normally use fancy animations with just a minimal input control set, and a lightweight runtime would allow MS to easily port SL to a large number of low power devices.
The apparent problem now is that SL is rather weighted with features -- many of which are appropriate only in larger screen environs, and this limits the potential device audience. This is likely why WP7 required a more robust engine. Perhaps a simple solution would be to offer WP7 with the full runtime, but publish lightweight runtimes for the rest of the mobile universe. This would give WP7 a control set edge, and at the same time, would allow most (efficiently coded) apps to cover the bulk of the device universe.
The iPhone and other market-significant proprietary boxes will quite likely be pressed by market forces or lawsuits into support other runtimes, such as Flash and SL. A lightweight runtime option makes SL more palatable to these vendors, since they wish to protect product performance perceptions, but at the same, wish to enjoy revenues from app sales. (Handled device suggestion)


Silverlight is not and never will be the one tool to use for all situations but it continues to be a very useful tool for many situations.
I'm typing this on a iPad and so I cant use many of my own Silverlight apps in the same way that Flash isn't available to me.
After lunch I'll go back to my desk and continue to work on my current Silverlight project which is the best tool for that particular project and environment with some support software being written in MVC2 for the web.
To get angry for being told Silverlight won't run on iPads and some other environments is madness, we already know this. If you want to hit every environment, use an open standard like H5 and accept the limitations that come with it. Judge on a project by project basis. (kaseciu pildymas)


I understand your point and your choice of client side technology is the most reasonable choice given the platforms you are targetting. However that does change nothing about Javascript not being suitable for complex client application development. I believe that the main reason for the choice has nothing to do with Javascript qualities as a language and development technology rather than the simple fact that Javascript is available on all those platforms and Silverlight is not. And I believe you would seriously consider Silverlight or other technology based on statically typed language, full cross-browser and cross-platform compatibility etc. if it was supported on all those platforms.
My understanding of Microsoft's message is "we are not able to put Silverlight on every platform so we are moving to HTML5/Javascript". And my fear is that it will slow down and with time maybe even stop Silverlight development and expansion because Microsoft "already has a strategy to get you everywhere" so why invest to Silverlight. Or at very least "why invest to Silverlight in a pace like last years", which is also disappointing.
HTML5 is a must have, there is no doubt about it, but it should not affect Silverlight in any way. (Martin)


I am not sure why so many people blame Microsoft for their commitment to Silverlight. It was quite clear from the beginning that Silverlight will be only available for Windows platform. I don't think this decision changed to much. If you stick with Widows platform you will be fine in any case. If you wanted to have a cross platform solution Silverlight was never a good choose or did some of you naively think that it will be ported to other platforms? (Aleximo)


I commited our development team and reputation to Silverlight. And now I have been left high and dry ! I am not really convinced by this Blog Post. The message is out there, Microsoft is adopting HTML5 in preference to developing Silverlight further. Microsoft are just going to let Silverlight die, after a couple more weak releases. Shopw me the Silverlight Roadmap for the next 5 years, on the Main Microsoft.com page, and maybe you will convince the Developer and their bosses that we have all not just adopted a turky technology.
I should have learn't from the J++ experiment.
I will never trust MS again. (No longer trust Microsoft)

I think some of you are missing the big picture. Whether or not Silverlight's direction has "shifted" or whether or not HTML5 is a full replacement is tangential at best to the point Bob made in his original quote.
Many of you have been saying Silverlight is "cross platform". If we were in the 90s, this would be right, it covers multiple browsers on the two largest operating systems.
Bob's comments are simple: web development is not about cross browsers, and it's definitely not about two operating systems. The ecosystem of web applications on a broad scale is widening greatly to include many new OSes, hardware types, form factors, screen sizes, hell even bandwidth assumptions are up in the air at this point.
If you wanted a "cross platform" web site or web application, Silverlight isn't and never was the right answer. The only difference between last week and this week is that Bob pointed out that it is infeasible to port Silverlight to all of these devices, form factors, and platforms. That should have been obvious to anyone knowledgable enough to be on this thread; him saying it is just a rubber stamp on something intuitively true.
This was true last week and it'll be true next week: If you're trying to come up with a desktop application that is loaded through a web interface, and you're okay with only supporting two operating systems, Silverlight will give you some nice bells and whistles for grander application. However, if you're looking to make a truly cross platform web solution, you need to be using HTML and its related standards and technologies. (ChrisC)

El panorama está dado...Hay otros elementos de gran interés, que en todo caso, irán en otro momento. Por ahora es suficiente. Un común denominador entre tantos desarrolladores del ecosistema de productos de Microsoft, es la nula referencia entre todos ellos a herramientas de desarrollo basado en modelos, o al menos, referencias a lenguajes específicos de dominio,  a pesar que durante dos años el tema fue un caballo de batalla de Microsoft. Sin embargo, en el fárrago de lenguajes y arquitecturas, éste debiera ser el punto que les diera perspectiva y tranquilidad ante abruptos cambios de frente o apariciones de nuevas arquitecturas. Un elemento general es el sentido de decepción y vacío, frente a la inversión de horas y dinero, cuando el dueño de un producto los deja solos y sin respuesta. Una estrategia no recomendable, existiendo la alternativa del desarrollo basado en modelos, en el sabor que se desee.

Crece la industria del software en Argentina

Cecilia Novoa publica a comienzos de noviembre en IProfesional una nota sobre el crecimiento de la actividad de IT en Argentina, que comienza a representar cifras de real peso: el número de personas ocupadas es similar al que emplea la industria automotriz. Sin embargo, como en otros mercados, sigue siendo inferior a las necesidades la promoción de nuevos profesionales desde las Universidades.

El fuerte crecimiento que el sector informático experimentó en los últimos años lo posicionó "cabeza a cabeza" con la industria automotriz en cuanto a la creación de empleos registrados.
El impulso de tan significativa expansión vino de la mano del lugar que encontró la Argentina en los mercados mundiales como plataforma exportadora de servicios.
Así, mientras la industria automotriz (entre terminales y autopartistas) cuenta con 77.362 empleos registrados, las actividades de Informática (desarrollo e implementación de software, consultoría, suministros de programas, servicios relacionados con bases de datos, procesamiento de datos y servicios de soporte, mantenimiento y reparación) le dan trabajo a unas 76.501 personas, señalan los datos del Ministerio de Trabajo al primer trimestre.
En lo que va del 2010, la incorporación de perfiles "tecnológicos" no para de crecer. La búsqueda de profesionales en el área de IT se incrementó entre un 40 y 50% entre enero y octubre de este año en comparación al mismo período de 2009, según estimaciones de la consultora Michael Page International Argentina.
Al respecto, Daniel Iriarte, Head-Office de la compañía en Buenos Aires, comentó que el dato viene a confirmar que el área de Tecnología de la Información (IT, en inglés) hoy se está constituyendo como uno de los sectores más activos y dinámicos de la industria regional.
De acuerdo al ejecutivo, entre los detonantes del alza incipiente en el rubro se encuentra, en primer lugar, la inversión tecnológica realizada en el país en el transcurso de los últimos períodos.
Asimismo, son relevantes las ventajas con que cuentan los especialistas IT locales, y que se expresan no sólo a través de su costo competitivo (dado el tipo de cambio) o sus similitudes culturales con polos demandantes en la industria, sino también en términos de su formación profesional y académica.
En tanto, Lucia Zunino, Project Leader y selectora especializada en el área de IT de la consultora, aseguró que "el sector informático fue el que más ha crecido en lo que va del 2010".
En base a las experiencias de sus empresas clientes, Zunino apuntó que la creciente actividad e intensidad en la contratación es una consecuencia de la importante cantidad de proyectos que venían postergados o "freezados" y que este año se retomaron.

La contracara del fénomeno
Sin embargo, la contracara de este cambio es la falta de recursos calificados para cubrir las diferentes posiciones que requieren las empresas, ya sean multinacionales o Pyme.
Según los expertos, la famosa "escasez de talentos" en el mercado de las Tecnologías de la Información se siente cada vez más.
Es que, por ejemplo, la cantidad de egresados de las carreras vinculadas a Informática no crece al ritmo que lo hace la industria. De hecho, desde la Cámara de Empresas de Software y Servicios Informáticos de Argentina (CESSI) alertan que de 3.275 (2009) los graduados bajarán a 2.783 para el 2011.
En la actualidad, detalla el siguiente gráfico, el grueso de los empleados de esta industria cuenta con un nivel universitario completo (38%) o incompleto (31 por ciento).

En este sentido, el gerente de la división de Finanzas & IT de Michael Page, Miguel Carugati, advirtió que "hoy resulta esencial que se trabaje en función del aumento del porcentaje de profesionales formados técnicamente y preparados para enfrentar las exigencias del mercado actual".
Los más buscados
En la actualidad, las empresas buscan profesionales no sólo orientados a lo técnico y operativo, sino que también estén enfocado al negocio, con la habilidad de vincular conocimientos especializados con aspectos referentes al presupuesto y la perspectiva de crecimiento económico de una compañía.
Según Michael Page, los perfiles más solicitados en este momento son:

1. Especialistas que ocupen cargos gerenciales en el área de IT
2. Profesionales del sector de ERP (SAP en especial)
3. Personal para las áreas de Project Management y Analistas Funcionales.

De acuerdo a Zunino, la demanda proviene de empresas de línea que necesitan reforzar sus áreas de Sistemas, pero sobre todo de consultoras de desarrollo que venden sus servicios tanto al mercado interno como externo.
En este último grupo de compañías, el caso de Globant, compañía dedicada a la creación de productos de software, es más que ilustrativo.
En lo que va del año, la firma lleva reclutados unos 1.000 nuevos perfiles y espera finalizar el 2010 con un total 2.300 empleados. De cara al 2011, la apuesta es aún más fuerte: sus directivos estiman sumar al equipo entre 1.500 y 2.000 personas.
En diálogo con iProfesional.com, el líder de las prácticas de desarrollo de productos de software (CTO) y del área de Human Capital de Globant, Guibert Englebienne, contó que "estamos buscando profesionales con cierto seniority, pero también perfiles muy específicos como, por ejemplo, con mucho conocimiento en matemática o física para trabajar en el desarrollo de las herramientas de animación para películas.
"Nos cuenta encontrar este tipo de joven profesional. Estamos apuntando a PHP, gente de doctorados o muy buenos programadores", admitió Englebienne.
Como parte de su expansión, Globant optó este año por "federalizarse" y regionalizarse: abrió oficinas en Tandil, La Plata, Córdoba, Rosario, Chaco, Montevideo y recientemente en Bogotá, al tiempo que también duplicó su espacio en Buenos Aires. Y, en el corto plazo, la meta será desembarcar en Estados Unidos, creando centros de delivery de servicios en Sillicon Valley.
Los salarios
De acuerdo a datos de la CESSI, en promedio las remuneraciones de la industria del software son un 35% superior a la de otros sectores productivos registrados.

"Este sobresueldo que venimos pagando crece año a año", resaltó en diálogo con iProfesional.com el presidente de la cámara, Fernando Racca.
Y como si esta diferencia no fuera de por sí significativa, los niveles salariales son aún superiores en las empresas tecnológicas y en aquellas cuyo negocio principal es el desarrollo de software, en comparación con las áreas de Sistemas de las compañías de línea.
E incluso, en algunos casos puntuales, la escasez provoca una marcada arbitrariedad a la hora de acordar los salarios.


Tal como muestra el gráfico a continuación y teniendo en cuenta el 18% promedio de ajuste que -según un relevamiento de la consultora Mercer- se otorgará en el sector High Tech, a diciembre de 2010 las remuneraciones del serán:

Desde Michael Page, Zunino no dudó en señalar que "los salarios del sector IT están por encima de la media del mercado" y que "en las empresas propiamente de Sistemas son más altos aún".
"A las compañías se les dificulta mucho la incorporación de un nuevo profesional, en un mismo rango de seniority, como puede ser analista senior, con el área de Finanzas o Supply Chain y les impacta mucho en la estructura de remuneraciones, ya que tienen que pagarle más porque son posiciones difíciles de conseguir en el mercado", advirtió la consultora.
En línea con los datos provistos por la firma de análisis de mercado Prince & Cooke, Zunino apuntó que "la remuneración varía de acuerdo a tecnología, pero el salario de un analista senior puede llegar fácilmente a los $8.000 brutos, un sueldo que en otras áreas corresponde a los niveles de jefatura".
Y añadió: "En este mercado, los profesionales van a las entrevistas sabiendo que tienen las de ganar y que pueden llegar a conseguir el salario que tienen en mente. Sin embargo, esto crea hipotecas que en un futuro pueden terminar pagándose."
En esta línea, Juan Martín Giachino Chavez, director de RH Humans Group, una firma especializada en selección de perfiles de IT, manifestó que "como las empresas que trabajan las últimas aplicaciones de IT tienen que asegurarse los recursos para trabajar y cumplir con determinados plazos y proyectos, no especulan con los sueldos, sino que ofertan lo máximo posible para tener los recursos."
Al igual que Zunino, el consultor aseguró que "al haber poca demanda de especialistas en nuevas tecnologías como .NET y Flex, entre otras, en muchas ocasiones son los mismos candidatos quienes determinan la remuneración para trabajar".

En tanto, Verónica Contin, selectora de Recursos Humanos también experta en perfiles IT, sostuvo que "entre estos perfiles muchas veces entra en juego la especulación".

Y añadió: "Para aceptar un puesto, los candidatos suelen establecer requisitos como cuatro semanas de vacaciones, trabajo part time por el mismo salario que full time, bonus anual, perspectivas de crecimiento a corto plazo y hasta la condición de que la distancia del trabajo a la casa no supere las diez cuadras o sea dentro del mismo barrio donde reside".

Oyendo reflexiones sobre el software futuro

Mencionado por Jean Bezivin en Twitter: algunas reflexiones de Michael Nygard acerca del futuro del desarrollo de software, que suenan razonables, aunque quizá a Java le reste más (y mejor) recorrido que el que Michael estima. Lo fundamental, la computación móvil y su asociada, la "computación en la nube", aparecen forzando la marcha según sus requerimientos:

• Two obvious trends are cloud computing and mobile access. They are complementary. As the number of people and devices on the net increases, our ability to shape traffic on the demand side gets worse. Spikes in demand will happen faster and reach higher levels over time. Mobile devices exacerbate the demand side problems by greatly increasing both the number of people on the net and the fraction of their time they are able to access it.

• Large traffic volumes both create and demand large data. Our tools for processing tera- and petabyte datasets will improve dramatically. Map/Reduce computing (a la Hadoop) has created attention and excitement in this space, but it is ultimately just one tool among many. We need better languages to help us think and express large data problems. In particular, we need a language that makes big data processing accessible to people with little background in statistics or algorithms.

• Speaking of languages, many of the problems we face today cannot be solved inside a single language or application. The behavior of a web site today cannot be adequately explained or reasoned about just by examining the application code. Instead, a site picks up attributes of behavior from a multitude of sources: application code, web server configuration, edge caching servers, data grid servers, offline or asynchronous processing, machine learning elements, active network devices (such as application firewalls), and data stores. "Programming" as we would describe it today--coding application behavior in a request handler--defines a diminishing portion of the behavior. We lack tools or languages to express and reason about these distributed, extended, fragmented systems. Consequently, it is difficult to predict the functionality, performance, capacity, scalability, and availability of these systems.

• Some of this will be mitigated naturally as application-specific functions disappear into tools and frameworks. Companies innovating at the leading edge of scalability today are doing things in application-specific behavior to compensate for deficiencies in tools and platforms. For example, caching servers could arguably disappear into storage engines and no-one would complain. In other words, don't count the database vendors out yet. You'll see key-value stores and in-memory data grid features popping up in relational databases any day now.

• In general, it appears that Objects will diminish as a programming paradigm. Object-oriented programming will still exist... I'm not claiming "the death of objects" or something silly like that. However, OO will become just one more paradigm among several, rather than the dominant paradigm it has been for the last 15 years. "Object oriented" will no longer be synonymous with "good".

• Some people have talked about "polyglot programming". I think this is a red herring. Polylgot is a reality, but it should not be a goal. That is, programmers should know many languages and paradigms, but deliberately mixing languages in a single application should be avoided. What I think we will find instead is mixing of paradigms, supported by a single primary language, with adjunct languages used only as needed for specialized functions. For example, an application written in Scala may mix OO, functional, and actor-based concepts, and it may have portions of behavior expressed in SQL and Javascript. Nevertheless, it will still primarily be a Scala application. The fact that Groovy, Scala, Clojure, and Java all run on Java Virtual Machine shouldn't mislead us into thinking that they are interchangeable... or even interoperable!

• Regarding Java. I fear that Java will have to be abandoned to the "Enterprise Development" world. It will be relegated to the hands of cut-rate business coders bashing out their gray business applications for $30 / hour. We've passed the tipping point on this one. We used to joke that Java would be the next COBOL, but that doesn't seem as funny now that it's true. Java will continue to exist. Millions of lines of it will be written each year. It won't be the driver of innovation, though. As individual programmers, I'd recommend that you learn another language immediately and differentiate yourself from the hordes of low-skill, low-rent outsource coders that will service the mainstream Java consumer.

  (...) 

• To my great surprise, data storage has become a hotbed of innovation in the last few years. Some of this is driven by the high-scalability fetishists, which is probably the wrong reason for 98% of companies and teams. However, innovations around column stores, graph databases, and key-value stores offer developers new tools to reduce the impedance mismatch between their data storage and their programming language. We spent twenty years trying to squeeze objects into relational databases. Aside from the object databases, which were an early casualty of Oracle's ascension, we mostly focused on changing the application code through framework after framework and ORM after ORM. It's refreshing to see storage models that are easier to use and easier to modify.

  (...) 

El peso de Internet en la economía inglesa

Estudio de Google comentado por BBC: Internet representaría el 7,2% del producto bruto del Reino Unido, lo que convierte a los negocios en y con la red en su quinto sector por volúmen. El estudio fue encargado por Google al Boston Consulting Group. Dice BBC:

UK internet economy 'worth billions'

The internet is worth £100bn a year to the UK economy, a study has concluded.

The research, which was commissioned by Google, found that the internet accounts for 7.2% of the UK's gross domestic product (GDP).
If the internet was an economic sector it would be the UK's fifth largest, said the report from the Boston Consulting Group (BCG).
This would make the sector larger than the construction, transport and utilities industries.
Central pillar
Some 60% of the £100bn a year figure is made up from internet consumption - the amount that users spend on online shopping and on the cost of their connections and devices to access the web.
The rest comes from investment in the UK's internet infrastructure, government IT spending and net exports.
The report, The Connected Kingdom: How the internet is transforming the UK, says that the internet's contribution to GDP is set to grow by about 10% annually, reaching 10% of GDP by 2015.

The UK, according to the report, is the world's leading nation for e-commerce. For every £1 spent online to import goods, £2.80 is exported.

"This is the opposite of the trend seen in the offline economy, which exports 90p for every £1 imported," the report says.

Internet companies play a vital role in employment with an estimated 250,000 staff, the report finds.

Small businesses that actively use the internet report sales growth more than four times greater than that of less active companies.

The report also attempts to compare the UK to other countries in the Organisation for Economic Co-operation and Development (OECD).
Under its scoring system, the UK ranks sixth, above Germany, the US and France. The highest ranked country is Denmark.
"The internet is pervasive in the UK economy today, more so than in most advanced countries," said Paul Zwillenberg, partner with BCG.

"Several industries - including media, travel, insurance and fashion - are being transformed by it."

Matt Brittin, managing director of Google UK, said: "The internet is a central pillar of the UK's economy.
"The sector has come of age, and with great prospects for further growth the UK internet economy will be vital to the UK's future prosperity," he added.

 El estudio, además de analizar con detalle su participación interna, compara  Reino Unido al resto de países que encabezan el uso de Internet. Entre ellos, y en posición relegada (alrededor del vigésimo puesto), sólo España se gana un lugar entre las naciones iberoamericanas.

TPS: su historia en un gráfico

Pete Abilla, lectura frecuente sobre Lean Manufacturing, reproduce una historia gráfica de los hitos fundamentales de la génesis del sistema Toyota (TPS), acompañada de una descripción algo más extensa. Para quienes tengan interés en la historia de su sistema de producción y sus raíces.

El original de esta historia tiene dos fuentes: la línea histórica textual publicada en Superfactory (ya comentada en otro momento aquí), y el grafico generado sobre su base por Rick Ladd.

Estrategias de inversión en España

Hace ya varios días comenta Javier Garzás, de Kibele Consulting, a propósito de la actualidad de los planes estratégicos españoles en tecnología:

En España, el Ministerio de Industria recortará un 24% sus inversiones a las TIC en 2011. Era de esperar. Se veía venir. Terminaron las inversiones importantes del estado en tecnología. Y, ojala me equivoque, pero aunque dicen que mantendrán los planes avanza, aquellos donde se incluían ayudas para la certificación de empresas en CMMI, ISO 15504, ISO 20000 e ISO 27001, en los próximos años va a rozar lo imposible obtener una ayuda. Y eso que decían que querían cambiar el modelo productivo de España. Pues no será pensando en la tecnología, que con el 24% de recorte, lidera la reducción de presupuestos por delante de turismo (un recorte del 16,3%), industria (11,8%), energía (17,2%) y, atentos, la subida del 23,4% en comercio exterior.

Según leo por ahí, las razones que da el Gobierno son sus nuevos objetivos de “austeridad, eficiencia en el gasto público e impulso al cambio de patrón de crecimiento productivo”. ¿Y cuál será el plan para cambiar el modelo productivo? Si por los recortes parece que las TIC no entran en el nuevo modelo productivo… ¿será un nuevo plan E? En serio, que nadie se ría, que aquel famoso y “brillante” plan E supuso 5000 millones euros, destinados muchos de ellos a quitar aceras para luego volverlas a poner (o incluso para crear discotecas), y en 2011 el presupuesto de la Secretaría de Estado de Telecomunicaciones será de 1116 millones. Sin duda una clara estrategia para cambiar el modelo productivo de España.

Profundo error estratégico gubernamental. Así lo hizo notar a nivel bancario Emilio Botín, presidente del Banco Santander y Universia:  "sería un error" no hacer un esfuerzo para incrementar las inversiones en educación universitaria y en investigación e innovación porque, según ha afirmado, "la sociedad española se enfrenta a desafíos importantes, propios y globales, cuyo desenlace condicionará el futuro de las nuevas generaciones" (...) "Los países son aún más conscientes de que de la necesidad de impulsar las universidades hacia la excelencia y reforzar su papel en I+D+i", ha indicado el presidente de esta entidad financiera, para el que la cooperación entre universidades, empresas y administraciones "es cada vez más importante". (Comentado en El Economista).

Estadísticas informales del predominio de Google (en Internet)

Leído en Denken Über: Pingdom publica algunas estadísticas no muy formales de distintas áreas de Internet que muestran un abrumador predominio de Google en áreas estratégicas: buscadores (usuales y móviles), publicidad, video, alimentadores de noticias, herramientas de análisis, mapas, etc. Una visión gráfica de su agresiva actividad de expansión de negocios. Un predominio que le puede hacer falta, pero  que no necesariamente significa hegemonía en la industria. Enfrente, la creciente oposición de sus competidores, cada vez más basada en la persecución judicial argumentando patentes, violaciones a la privacidad, dominio de mercado y otras. Una disputa de hegemonías que sería interesante recapitular. Trataremos de hacerlo...

Oracle/Java: Golpe de timón de IBM?

Leído primero en Infoq, y luego en todos lados...IBM anuncia que colaborará con Open Java Community (OpenJDK):

REDWOOD SHORES, CA & ARMONK, NY - 11 Oct 2010: Oracle (NASDAQ: ORCL) and IBM (NYSE: IBM) today announced that the companies will collaborate to allow developers and customers to build and innovate based on existing Java investments and the OpenJDK reference implementation. Specifically, the companies will collaborate in the OpenJDK community to develop the leading open source Java environment.
With today's news, the two companies will make the OpenJDK community the primary location for open source Java SE development. The Java Community Process (JCP) will continue to be the primary standards body for Java specification work and both companies will work to continue to enhance the JCP.
The collaboration will center on the OpenJDK project, the open source implementation of the Java Platform, Standard Edition (Java SE) specification, the Java Language, the Java Development Kit (JDK), and Java Runtime Environment (JRE).
Oracle and IBM will support the recently announced OpenJDK development roadmap, which accelerates the availability of Java SE across the open source community.
"The Java community is vital to the evolution of the Java platform," said Hasan Rizvi, senior vice president, Oracle. "The collaboration between Oracle and IBM builds on the success of OpenJDK as the primary development platform for Java SE."
"IBM, Oracle and other members of the Java community working collaboratively in OpenJDK will accelerate the innovation in the Java platform," said Rod Smith, vice president, emerging technologies, IBM. "Oracle and IBM's collaboration also signals to enterprise customers that they can continue to rely on the Java community to deliver more open, flexible and innovative new technologies to help grow their business."
Java is a general-purpose software development platform that is specifically designed to be open and enable application developers to "write once, run anywhere." The platform is most widely used in business software, web and mobile applications.

Una ola de comentarios sobre este movimiento. Existe coincidencia en que este acuerdo, más allá de todo lo positivo que pueda tener, también tiene un perdedor: la implementación de Java Apache Harmony, de la cual participa IBM y colisiona con OpenJDK. Dice InfoQ:

InfoQ asked if IBM would continue to support both Apache Harmony and the other ASF projects with which it is involved. Smith suggested that they would, but also made it clear that IBM would be shifting its development effort from Apache Harmony to the OpenJDK. As part of this, Smith noted that IBM could bring some innovations from the Harmony project across to the Java SE Reference Implementation.

¿Qué rumbo tomará Java ahora? InfoQ recoje algunas opiniones positivas:
De Mike Milinkovich, de la Fundación Eclipse:

Today’s announcement that IBM is going to join forces and work with Oracle on OpenJDK is good news for Java, and by extension for Eclipse. All of us who live within the Java ecosystem need to recognize that this fundamentally strengthens the platform, enhances the business value of Java and offers the hope of an increased pace of innovation.
Although it will take a while for all of the ramifications and reactions to become clear, at its face the announcement challenges the conventional wisdom that the future of Java is going to be a fractured one. Some recent examples of these expectations can be seen in blog posts like James Governor’s “Java: The Unipolar Moment, On distributed governance for distributed software” and Joseph Ottinger’s “The Future of Java: forking, death, or stasis”. When I read them just a short time ago, I thought they accurately reflected the likeliest outcomes for Java’s sure-to-be fractious future. Now I am much more optimistic that we can get back to innovation.
To me the overarching motivation is obvious. Both IBM and Oracle have a shared interest in assuring their enterprise customers that Java was, is and always will be the safe technology choice that they’ve been selling for the past ten to fifteen years. As much fun and excitement as a further escalation of the “Java Wars” would have been, both companies have a very large vested business interest in combining forces, closing ranks and focusing on reassuring their customers that Java should remain their platform of choice.
This announcement fundamentally alters the equation in at least three important ways.

• The presumption of conflict: Implicit in almost all of the recent writings on the future of Java is the notion that IBM’s interests would lie in direct competition, if not outright conflict with Oracle’s. Many have been assuming that IBM would eventually snap and declare war on Oracle’s Java hegemony, with the battles being fought in places like OSGi, Apache and Eclipse. It is now apparent that is not going to happen. Furthermore, now that IBM is working with Oracle on OpenJDK, we can expect a lot more mutual support within the JCP on driving specifications, especially platform specifications, forward.
• Oracle is focused on reviving the business of Java: In case you hadn’t noticed, Oracle’s stewardship of Java is going to be a significant departure from Sun’s. As Amy Fowler said “…this is a practical company who isn’t suffering from an identity crisis and knows how to make money from software.” A couple of thoughts on the differences: First and foremost Oracle actually has resources to invest in moving Java forward, whereas Sun’s financial weakness prevented forward progress for at least the past three years. Second, Oracle is putting in place the software engineering discipline and process in place to ensure that future releases of Java can happen on a much more reliable and predictable timetable than Sun. Third, Oracle is large enough and confident enough in its execution that it is much more comfortable in striking business deals with its co-opetition such as IBM. It will be darn interesting to see if they are successful in signing up more participants down the road. And finally, there will be less talk about community-driven motivations and more focus on the business. In my opinion, all but the last of those are unequivocally positive. But Oracle’s current focus on the business at least offers the hope that it may pay community dividends down the road. It is a lot easier for large companies to consider community motivations when they’re profitable and feel that they have momentum on their side. The past couple of years of Java have been years of stalemate, lack of innovation and lost opportunities. Turning that around has to be job one if Oracle is going to see a return on its acquisition.
  
• This is an inflection point in the Oracle-IBM relationship: If you think back a few years ago, IBM and BEA were two companies who competed fiercely in the Java marketplace, but managed to collaborate on many JCP specifications and in numerous open source projects at places such as Apache and Eclipse. It was a mature industry relationship. Maybe I’ve missed it, but I haven’t seen a similar historical pattern with IBM and Oracle, even after Oracle acquired BEA. This is an important step in the relationship between the two companies, at least in the Java space. Hopefully it is a harbinger of additional collaboration.

The big question is what are going to be the reactions of the other significant players in the Java ecosystem. The actions of Google, SAP and VMware in particular will all be interesting to watch.

 De Mark Reinhold, Chief Architect de Java Platform Group en Oracle:

I’m very pleased that IBM and Oracle are going to work more closely together, and that we’re going to do so in the OpenJDK Community. IBM engineers will soon be working directly alongside Oracle engineers, as well as many other contributors, on the Java SE Platform reference implementation— starting with JDK 7.
I expect IBM’s engineers to contribute primarily to the class libraries, working with the rest of us toward a common source base for use atop multiple Java virtual machines. We each have significant ongoing investments in our respective JVMs; that’s where most of the enterprise-level feature differentiation between our respective products is found, and it makes sense for that to continue. Focusing our efforts on a single source base for the class libraries will accelerate the overall rate of innovation in the JDK, improve quality and performance, and enhance compatibility across all implementations.
Our tighter collaboration will be evident not just in OpenJDK but also in the Java Community Process. IBM has endorsed Oracle’s proposal for Java SE 7 and Java SE 8, which already has strong support from across the community. We’ll also join forces to enhance the Java Community Process so that it remains the primary standards body for Java specifications.
This is excellent news, for the Java SE Platform and for OpenJDK. I’ve gotten to know many of IBM’s top Java engineers over the years, and I now look forward to working more closely with them.

También es muy importante la opinión de Bob Sutor, con larga responsabilidad en este área en IBM:

When people talk about open source, the notion of “forking” often comes up. The idea is that some folks are not happy with the direction in which a project is going, so they take a copy of the source code, come up with a new name, and set up shop elsewhere. This is no guarantee that the newly forked project will be successful, but it functions as an important escape valve for those who have donated time and effort to a community project and want to see the work done in what they believe is the right manner.
You less often hear about what I’ll call a “reverse fork”: people developing largely similar but separate projects who decide that they instead want to work together. They can do this for a variety of reasons but it all comes down to “burying the hatchet” or otherwise resolving their differences for the sake of the project.
(...) IBM will work with Oracle and the Java community to make OpenJDK the primary high performance open source runtime for Java. IBM will be shifting its development effort from the Apache Project Harmony to OpenJDK. For others who wish to do the same, we’ll work together to make the transition as easy as possible. IBM will still be vigorously involved in other Apache projects.
We think this is the pragmatic choice. It became clear to us that first Sun and then Oracle were never planning to make the important test and certification tests for Java, the Java SE TCK, available to Apache. We disagreed with this choice, but it was not ours to make. So rather than continue to drive Harmony as an unofficial and uncertified Java effort, we decided to shift direction and put our efforts into OpenJDK. Our involvement will not be casual as we plan to hold leadership positions and, with the other members of the community, fully expect to have a strong say in how the project is managed and in which technical direction it goes.
We also expect to see some long needed reforms in the JCP, the Java Community Process, to make it more democratic, transparent, and open. IBM and, indeed Oracle, have been lobbying for such transformations for years and we’re pleased to see them happening now. It’s time. Actually, it’s past time.
Ultimately this is about making Java more successful and pervasive than ever before. Java is not about any single company’s technical direction and it helps prevent lock-in. It runs on many, many different operating systems and hardware platforms. As a blatant plug, let me say Java runs exceptionally well on Linux and IBM’s System z, POWER, and Intel-based hardware. Indeed Java is one of the open standards that makes System z the amazingly interoperable platform that it is.
Java is about compatibility and always has been. It’s not been easy to maintain runtime environments that are consistent across platforms while exploiting the underlying features and performance advantages of those platforms. With this newly unified OpenJDK open source project, we can give customers the confidence they need to continue to invest in Java-based solutions knowing that they will get the best technology, the most important innovations, and the tightest collaboration among industry leaders.
We believe that this move to work together on OpenJDK is in the best interests of IBM’s customers and will help protect their investments in Java and IT technology based on it.
So to summarize my opinions on this: OpenJDK represents the best chance to provide a top notch unified open source runtime for Java; customers will benefit by having first class Java open standards developed collaboratively and constructively; and our energy will be focused on working together and optimizing our joint work, rather than wasting time on duplicative projects.

De las opiniones críticas, hay una especialmente didáctica: la de Paul Fremantle, participante de proyectos de la fundación Apache, y coincidente en puntos esenciales con Sutor:

This week IBM announced it would be supporting Oracle's OpenJDK. At first glance it seems like "Great!"
Isn't it good that two big supporters of Java are getting behind a single open source project?
Well, in my personal opinion, no. It is bad. Bad for Java. I'll try to explain why.

The first point is that IBM are not just saying they will support OpenJDK. They are also saying that are pulling effort out of Apache Harmony. Apache Harmony is a project to build an Open Source JVM under the Apache license, rather than the GPL which is the license under which OpenJDK is available.

Harmony significantly predates OpenJDK and parts of Harmony are widely distributed in Android phones. Unfortunately there is a huge cloud over Harmony right now, and this news just made that cloud a good deal blacker. The lack of some IBM committers on the project isn't the problem. Apache encourages enough diversity that projects live on when one company pulls out.

To understand the clouds over Harmony let's first look at the legal situation here. Intellectual property, as we all know, is protected by two main models: copyright and patents. Simplifying hugely, copyright is about copying code, patents about copying ideas.

Apache Harmony was designed and built as a clean room implementation of Java. So no code was copied from any existing copyrighted JVM. But that doesn't protect against copying ideas - because even if the developers came up with the same idea independently, the patent still applies.

So how do Open Source projects protect themselves against patent issues?

The main way is to work with Open Standards that are covered by Open Specification promises or "Royalty Free" patent licenses. This is where major IP owners such as IBM and Microsoft have stated that they will not exert patent rights over either Open Source or Open Standard implementations of a particular standard.

Likewise most new standards from organizations such as OASIS are built on a Royalty Free basis, which means that all the companies that helped author the standard offer a free patent license to anyone implementing the standard.

There is a model under which Sun (and now Oracle) offers protection from patent issues: The Java Specification patent grant says that as long as you fully implement the Java specification and pass the tests that prove it - the Technology Compatibility Kit (TCK) - then you have a perpetual royalty-free license to patent rights that Oracle has over Java.

This sounds great. Not only has Sun/Oracle has made available Java under an Open Source license (GPL), but if you don't want to use GPL you can simply write another JVM that conforms to the tests and you won't be sued for patent infringement. Perfect. So what on earth are those whiners at Apache bothered about?

Unfortunately it isn't quite so simple. I hope you are following me so far. All Apache Harmony needs to do to protect against patent suits is to pass the TCK. Can Apache Harmony pass the TCK? Well, yes and no. Would it pass the TCK if the tests were run? Probably. Can the tests be run? No.

The TCK is not available to Apache in a way that allows Apache to run it. The JDK is available as Open Source, but the TCK isn't. To protect against patent issues, you have to talk to Oracle and get the TCK. And they will only give it to Apache with restrictions. In particular restrictions of a kind called Field of Use (FOU) restrictions.

Ok, this is becoming overly legal. I apologise. But I think its important to understand this story, because this really gets to the heart of how open Java is.

Open Source is not just "published code". If you take an Open Source library, then you are allowed to redistribute the code without prejudice. This is key to Apache and the Apache license. So Apache can't build in restrictions on who is allowed to take Apache code or what they can do with it. The Apache license doesn't allow it.

Unfortunately, Sun - and now Oracle - have said that they will only give the TCK to Apache if it restricts how the Harmony code can be used. Effectively what Sun/Oracle is trying to say is that Harmony code cannot be used by mobile devices (like Android). If Apache were to go along with this, it would mean shipping Apache Harmony under a different license from the Apache License. And this would no longer be Open Source.

Why not? Well a key part of the definition of Open Source is that there is no restriction on the Fields of Endeavour. In other words, if Apache agrees to the FOU restrictions that Oracle insists on, then the result would be that Harmony would not be Open Source. Naturally Apache cannot agree to that.

Let's recap. Anyone can create an Open Source JVM, but they cannot get patent protection unless they agree to Oracle's FOU restrictions, at which point it is no longer Open Source. Therefore no-one but Oracle can create an Open Source JVM without fear of being sued.

Ok, this all sounds highly legalistic and possibly quite theoretical so far. That was until Oracle sued Google over patents breached by Android phones running code from Harmony. The gloves are off. And the real result of this is that the only Open Source JDK that you can rely on having a patent grant is the OpenJDK. And if I modify OpenJDK then I am at the mercy of Oracle to grant me a TCK license.

Unfortunately this is simply bad for Java. Java as a language is threatened by many other new and old languages. For many users its simply a commodity runtime that they will use as long as it is commonly available. And knowing there are Open Source implementations that they can use is part of that decision. Knowing that there is effectively only one Open Source project that is free from Oracle's patent claims will affect the perception and the reality of Java's openness. And for many people the fact that this is under the GPL is an issue. You can see why IBM joined OpenJDK: Oracle has Apache Harmony in a tight place.

If you want to know more - as well as hearing the official Apache line as well as my own, then please take a look at Apache's letter to Sun when this first happened.

When this first blew up Sun was a struggling company that you could have argued needed the extra revenue Java licensing to mobile phones bought them, and which Harmony and Android threatened.

The question before us now is whether the same is true of Oracle, and whether Oracle is working in the best interests of its customers, the Java community, and the Open Source community. Do you believe that Oracle should license the TCK under an open license? And are you happy that despite the move to take Java Open Source, there really is no freedom to create Open Source implementations of the Java language.

The good news for Harmony is that Apache's diversity approach means that IBM pulling out won't harm the future of the code. The bad news is that there is one less company putting pressure on Oracle to make Java truly open.

Que Oracle piensa hacer valer sus patentes, lo demuestra la demanda abierta a Google por Android. Más allá de que los defensores de la fundación Apache se vean particularmente afectados, los reales hechos parecen darles la razón, aunque la decisión de IBM quizá tenga tanto valor como el esfuerzo de Apache en Harmony. Queda por ver si la voracidad no es enemiga de los buenos negocios.

Nota a los "Apuntes sobre Factorías de Software..."

Observo que en la recopilación bibliográfica faltan referencias a Jack Greenfield, Keith Short y sus trabajos sobre factorías de software (Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools, y otros documentos).  Una omisión involuntaria, básicamente porque sobre este tema se ha escrito mucho aquí mismo (1, 2). Solucionaremos su ausencia.

LinkedIn mejora sus herramientas

 LinkedIn continúa mejorando su funcionalidad. Ahora inaugura su LinkedIn Labs, haciendo públicos cuatro proyectos iniciales (NewIn 2.0, ChromeIn, Instant Search, y Signal). Este último tiene quinientas invitaciones para experimentar.

Signal: LinkedIn Signal is technology that we recently unveiled at TechCrunch Disrupt 2010. Discover the power of faceted search over both the LinkedIn stream and tweets shared by our users, and find insights you won’t find anywhere else. John Wang, one of the lead engineers, shares some details about the technology behind Signal that includes JRuby, Scala, Voldemort, Zoie & Bobo.

Apuntes sobre Factorías de Software,III

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

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

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

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

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

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

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

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

¿Dónde acabarán los reclamos de patentes?

A propósito de las demandas de Oracle y Microsoft contra Google y/o Motorola, podemos pensar que mañana Bell podría denunciar a todas las compañias telefónicas por usar "un sistema que transmite la voz por medios electrónicos", sin pagarles patentes...
¿Qué podríamos patentar? Luego, solo se trata de tener el abogado adecuado...En Infobae, pero también en otros medios:

Las denuncias contra el sistema operativo Android, de Google, se suman, ahora desde Microsoft, que acusó a Motorola por la violación de algunas patentes en sus teléfonos relacionadas con los avances que fue sufriendo cada versión del entorno creado por el gigante de Internet.
Microsoft acusó a Motorola ante la Comisión de Comercio Internacional (ITC, por sus siglas en inglés) y ante un tribunal de Washington por la violación de varias patentes en sus modelos que funcionan con Android. Es decir, los teléfonos de la familia Motorola Droid, que en Europa fueron redefinidos como Milestone y Dext.
La explicación llegó por parte del vicepresidente de Microsoft para asuntos corporativos, Horacio Gutiérrez.
En una nota publicada en uno de los blogs de la compañía acotó las demandas a aquellas "relacionadas con desarrollos en marcha en el campo de la telefonía inteligente".
Concretamente, con las funciones que los hacen "inteligentes", añade Gutiérrez, como la posibilidad de sincronizar cuentas de correo electrónico en tiempo real, Exchage ActiveSync.
Otra de los reclamos hace referencia al uso diario de estos modelos Android como gestores de agenda: citas, calendario, listas de contactos, etc.
En cuanto a los avances técnicos, Microsoft reclama a Motorola sobre las patentes para la gestión del espacio de almacenamiento y los indicadores sobre la señal de cobertura.
Tras distanciarse de Motorola, Microsoft llegó a un acuerdo con HTC para licenciar el uso de algunas de sus patentes sobre telefonía móvil en los Android del fabricante, una de las compañías que más beneficio ha sacado al sistema operativo móvil de Google. Sin embargo los términos del acuerdo no fueron publicados por lo que no es posible saber si hay algún tipo de incompatibilidades a este respecto.
Otra de las razones para impedir la evolución de Android está en la competencia directa que ejercerá contra su nuevo sistema operativo, Windows Phone 7, que aspira a ganar cuota del mercado de los smartphones, aumentando la satisfacción el cliente mediante la calidad.
El próximo 11 de octubre tendrá lugar la presentación oficial en Nueva York, previa al lanzamiento del teléfono días después en Norteamérica y los países más grandes de Europa.

ECIS, un nuevo reclamo contra las negociaciones de ACTA

Leído primero en Barrapunto: Las negociaciones del ACTA, tenazmente, siguen adelante. Ahora con un cuestionamiento abierto de varios de los grandes actores en la industria del software (tomado de NacionRed):

Una poderosa coalición empresarial liderada por Google Europa, la European Committee for Interoperable Systems (ECIS), en la que están representados también Adobe Systems, IBM, Oracle, Opera o Nokia, ha expresado su preocupación por la deriva negociadora del ACTA, que podía ser firmado en Tokio esta misma semana.
ECIS es una asociación fundada en 1989 para promover la interoperabilidad y la libre competencia, así como un entorno favorable para las soluciones TIC en Europa. Esto le ha llevado a estar en guerra permanente con Microsoft.
En concreto los socios de ECIS muestran su rechazo por la regresión que supone el Acuerdo Anti-Falsificación (ACTA) en relación con la ya de por si muy restricitva Directiva 2001/29/CE, en la que al menos se alcanzó el acuerdo, gracias al Parlamento Europeo, como reconocen textualmente los miembros de ECIS en el comunicado (pdf), para permitir eludir las medidas tecnológicas de protección de los programas de ordenador que permitan adecuar la interoperabilidad (con otros programas) y prevenir que poderosos jugadores obstaculicen la competencia y la innovación.

Pero ahora Google y el resto de empresas que forman parte de ECIS denuncian que ACTA no hace está excepción “Ninguna disposición del presente borrador del ACTA indica que tales disposiciones no se aplican a los programas de ordenador”.

Patentes de software

ACTA extiende el sistema de patentes de EE.UU al resto del mundo. Google y sus socios en ECIS ponen el grito en el cielo ya que se criminaliza la “infracción de patentes de software” con condena de cárcel incluidas ya en el borrador ACTA. Una nueva Inquisición mundial en la que los desarrolladores de software serán disuadidos para no tomar riesgos y continuar con el magnífico trabajo que están desarrollando en Europa.
ECIS denuncian con contundencia las gravísimas consecuencias de esta aspecto de ACTA:

El impacto sería particularmente grave en el ámbito de la interoperabilidad de software, donde la falta de una clara excepción sobre la interoperabilidad de las patentes permite a a los titulares de patentes amenazar a los desarrolladores alternativos.

La imposición de sanciones penales a los desarrolladores podrían agravar el daño aún más. Las consecuencias serían potencialmente aún más drásticas para los desarrolladores de código abierto en Europa que por miedo deberán abandona

Transparencia

Por último, ECIS saca los colores a la Unión Europea y le tiene que recordar a los políticos la importancia de la transparencia en las negociaciones sobre un acuerdo comercial con tantas repercusiones para la vida de los ciudadanos de todo el mundo y la propia actividad de las empresas.

La Comisión Europea y el Consejo deberían garantizar una mayor transparencia en las negociaciones sobre el ACTA. El Tratado de la Unión Europea (en lo sucesivo TFUE) reconoce que “con el fin de promover la buena gobernanza y garantizar la participación de la sociedad civil, las instituciones, organismos, oficinas los organismos de la Unión actuarán con la mayor apertura posible. Tomamos nota de que las negociaciones no se han realizado de conformidad con estas normas de transparencia

ECIS pide a la Comisión Europea y al Consejo de la Unión Europea que todas las partes sean escuchadas en este momento crucial de la negociación.

El comunicado completo de ECIS.
El último borrador conocido de ACTA.
El comentario de Enrique Dans.

Diseño dirigido por modelos, en tránsito

Jean-Jacques Dubray publica en InfoQ hace ya algunos días, algunas reflexiones sobre el desarrollo basado en modelos, indagando sobre su estado actual, y sus posibilidades de ganar terreno, o de sus dificultades para hacerlo. Su nota fue seguida por un buen número de comentarios, que dan también una idea aproximada del estado de su uso:

Ulrik Eklund published a summary of the keynote speech from Jon Whittle at the SPLC 2010 conference. In his talk, he presented some findings on experiences from using model-based development in industry from the EA-MDE project. The project is interested in understanding the factors that lead to success or failure with model-driven engineering (MDE) to help design the next generation of MDE tools. This question is not new, two years ago, Sven Efftinge, Peter Friese and Jan Köhnlein published an article "MDD best practices and Johan Den Haan, CTO of Mendix, published an article on the how an MDD initiative could fail. Adopting an MDE approach can be quite daunting. Then, Johan concluded his article by:

It’s not my goal to discourage you from starting with model-driven software development. I just wanted to show you the complexity of it and wanted to share some thoughts hopefully pointing you at directions helping you to overcome the complexity of MDE.

Two weeks ago he also published an article on his blog detailing the lessons he learned while building a Model Driven Software Factory and he reiterated the same skepticism:

I see Model Driven Software Development as an important part of the future of software development. However, I also see a lot of people struggle with actually using Model-Driven techniques and applying them in their daily business. It isn't trivial to build a successful Model-Driven Software factory (MDSF).

The question is actually quite popular. Last week, Marco Bramballi and Stefano Butti also published a presentation on the same topic while applying BPM and MDD to a Large Scale banking scenario with BPMN, WebML and WebRation.
In his talk, Jon provided some key success factors of a successful MDE approach, as he identified as part of his research:

1. Keep the domains (modelled, I assume) tight and narrow.
2. Target well known domains.
3. Put MDD on the critical path (he means that pilot projects never get sufficient attention and resources).
4. MDD works best form the ground up.
5. Be careful of gains that are offset elsewhere.
6. Don't obsess about code generation.
7. Not everyone can think abstractly.
8. Most projects fail at scale-up
9. Match tolls and processes to the way people think, not the other way around

In their articles, Swen, Peter and Jan also warned:

Our most important recommendation for the reader is: be pragmatic. DSLs and code generators can, when used appropriately, be an immensely useful tool. But the focus should always be the problem to be solved. In many cases, it makes sense to describe certain, but not all, aspects using DSLs.

Even though MDE is still evolving quite rapidly, Jon reports that 83% of the EA-MDE survey respondents "consider MDE a good thing".
After over a decade of Model Driven Architecture, Development and Engineering and which itself followed some rich Model Driven Development environments like NeXTStep that emerged in the early late 80s, models are everywhere, yet, in such a small quantity that our industry seems to still be looking for the path that will make Model-Driven approaches mainstream. Are we really in the position of defining "lessons learned" or "best practices" with so few successes reported? What is hampering us? Is it the focus and precisions of the model? Is it lack of tools? standards? Is is the level of abstraction that make it difficult for most people to create a viable software factory? What's your take on it?

A esta invitación final de Jean-Jacques a discutir le siguieron muchas e interesantes respuestas. Siguen algunas de ellas:
Rui Curado, autor de su propia herramienta, destaca algo que comparto:

Existing model-driven approaches were conceived by "top-notch" developers/mathematicians. This lead to the assumption that those who would use such approaches are "top-notch" developers too. And this is precisely what is happening: Current MDD practitioners belong to the "top 1%".
Most of the world's developer population (myself included) are what I call the "average developer mortal": developers who are good at their job without actually being "geniuses". People who do things the right way, but pragmatically. We are the "everyday programmer". MDD approaches and tools fail to address us

Sobre el enfoque orientado a objetos de las actuales herramientas orientadas a MDD, dice Dean Wampler:

[...] all the MDD approaches that I know of are based on objects. Unfortunately, objects have proven to be poor at defining reusable component standards. That's a controversial statement, but to prove it, ask yourself why the world's most successful "component" standards, like TCP/IP, HTTP, busses in digital electronics, etc. are not object oriented, while OO-based component standards, like CORBA, proved to be too complex to survive the test of time and to achieve ubiquitous, permanent adoption. (Still not convinced? "Design Rules, Vol. 1: The Power of Modularity" discusses the characteristics of successful modularity standards. Very few OO APIs meet those criteria.)

Dice Steven Kelly, sobre las condiciones para elaborar un modelo satisfactorio:

The key issues are:
1) use a language that is highly targeted, efficient and precise at describing the systems you want to build (and thus useless for most other systems)
2) generate production quality code that you don't need to look at or touch
3) use a toolset that makes creating the language, generators and models efficient, scalable and maintainable.

[...] Failing to reach (or even aim for) those 3 targets is what consigns most MDD attempts to mediocrity or failure. Using a tool or language because it's a "standard" or already in use is hardly likely to result in major productivity increases compared to normal. As Einstein said, insanity is doing the same things as before and expecting different results.

Steven, respondiendo a una pregunta de Dubray, dice, respecto a su afirmación de generación completa de código:

100% code generation is definitely the goal, and the norm is to achieve it. Here, 100% means 100% of the code that is specific to this model. There is of course hand-written code below the generated code: what we call the domain framework, i.e. code specifically written to complement this modeling language and generators, and which doesn't change per model.

In some cases a particular model may need an addition to the domain framework; in others models may contain snippets of code or refer to per-model functions that are hand-coded separately.

If by "custom models" you mean "custom modeling languages", then yes, at least that has been my experience. I'm not sure it's "inherently" true, but I think there are good reasons for it. Have you ever seen a tricky or laborious problem can be turned into something an order of magnitude faster and easier by applying the correct language? If so, you probably understand what I'm talking about. Obviously, in general development those situations were rare, because the right language didn't yet exist. DSM lets you create that "right language" for your needs.

Una vez más, un punto cuestionado es el uso de UML, que es confrontado con DSL (Domain Specific Languages). Por supuesto, Steven Kelly, uno de los gestores de Metaedit, es quien especialmente pone el acento en DSM (Domain Specific Modelling). Dice Kelly:

As Dean Wampler said, "Give me a language and APIs that let me express what I need to do very succinctly!" That of course is the whole idea of DSM, and why it is so different from (say) UML-based MDA. It's just a shame that working "code generation" often gets tarred with the same brush as approaches that have failed.

Of course, we're all constrained by what we have experienced personally, e.g. Dean saying that all MDD he has seen has been based on object-oriented languages (I guess referring to UML?). It's just a fact that by nature humans trust personal experience far more than even statistically significant research.

Dean said "Nothing beats a Turing-complete, textual programming language for expressivity and productivity." That may be true if you have to pick one language to use for every single task for your whole life. But for any given problem space, it's simply not true. Expressivity is the ability to say everything you want, precisely and concisely - which is as good a definition of a Domain-Specific Modeling language as you're likely to get. The consistent measured increase in productivity by a factor of 5-10 with DSM is a proven fact. And when you've actually seen DSM in practice, as opposed to code generation with UML or IDE wizards, it's obvious why it is so much faster throughout.

Jean-Jacques complementa la valoración de UML:

With respect to UML, I think the problem the industry doesn't see is that the OO metamodel is all but arbitrary. The structure of a class has nothing absolute. As such is has become a hindrance as more and more complex solutions cannot be efficiently described/implemented with a one size fits all concept. Of course all the ingredients I think are there in OO (object, property, method), but it is how they are combined that is inflexible. The tragedy with UML is to think that (abstracted) OO concepts are the foundation of modeling. They built the whole thing on the wrong foundation (MOF). As a result, people are using UML as an M3 layer, because MOF (or Ecore) is simply impractical to use.

Mi impresión: Sigue siendo un hecho que MDD es un concepto en construcción y evolución. Tras años de acento en UML como herramienta básica de elaboración de modelos, la no obtención de resultados robustos ha llevado a un punto en que se exploran otras alternativas. Probablemente, esa robustez llegará, y las variantes actuales serán sólo una parte de las herramientas que sobrevivan. Lo que no sucederá, es que el desarrollo vuelva atrás a herramientas que no impliquen generación de código y un grado alto de abstracción.