Este es un proyecto cancelado que no recibe actualizaciones. No obstante, puedes acceder a su archivo como referencia.

Versión Cero

Windows Vista y el efecto del segundo sistema

Sergio Montoro

Al intentar evolucionar un sistema de software pequeño y exitoso a veces lo convertimos en algo sobrediseñado y de complejidad inmanejable. ¿Será este el caso de Windows Vista?

por Sergio Montoro Ten, 26 septiembre 05

El efecto del segundo sistema es un concepto atribuido a Frederick P. Brooks en su libro The Mythical Man-Month según el cual la siguiente creación de los diseñadores de un software pequeño y elegante es un monstruo sobrediseñado e impracticable.

A esto yo lo llamo también, el síndrome faraónico, y existe más o menos en todas las profesiones (en política española lo llaman el síndrome de la Moncloa). Imbuidos del éxito de su primer sistema, los creadores proyectan una obra faraónica, cuyo propósito es más satisfacer el ego de su mecenas antes que resolver ningún problema concreto del mundo cotidiano.

La materialización práctica de este principio es la conocida ley de Brooks: añadir gente a un proyecto de software retrasado sólo lo retrasa aún más. Que podría estar relacionada con los problemas de gigantismo burocrático que se atribuyen últimamente a Microsoft.

Vista es aproximadamente el cuarto sistema de Microsoft, digo aproximadamente porque MS-DOS fue en realidad una compra, luego vino Windows 3.1 a partir del cual evolucionaron 95 y 98. E, independientemente, Windows NT, cuya fusión con 98 dió lugar a Windows 2000 (con algunos abortos de por medio como ME). XP es, básicamente, una revisión de 2000.
De modo que tras la introducción del interfaz gráfico de usuario Vista es el primer intento de Microsoft de crear algo completamente nuevo que no sea una evolución de lo anterior.

Es posible encontrar referencias a un sistema de ficheros con características de base de datos como WinFS en el anuncio de Cairo de fechas tan tempranas como 1995. Hasta que finalmente Jim Alchin tuvo que anunciar en agosto de 2004 que eliminarían WinFS de Longhorn para no retrasar más las fechas previstas de lanzamiento.

Las propias ideas sobre arquitectura de software de Bill Gates, probablemente contribuyen a agravar el problema. Desde que en el año 2000 Gates dejó la presidencia ejecutiva de Microsoft en manos de Steve Ballmer para ocupar el cargo de arquitecto jefe, Gates ha seguido fomentando una estrecha integración entre todos los productos de Microsoft. Basándose en un principio muy viejo de Microsoft llamado “sincronizar y estabilizar“ Gates pretende aprovechar el poder monopolístico de MS-Office y Back-Office creando sinergias únicas entre todos los productos de Microsoft.
Es fácil ponerse a criticar este modelo argüiendo que los productos de Microsoft deberían ser más desacoplados e independientes para dar mayor flexibilidad y velocidad a cada equipo de desarrollo. Pero lo cierto es que lo que justamente no han conseguido emular los competidores Open Source basados en el modelo del Bazar es justamente el ecosistema completo de aplicaciones de Microsoft.

Se sabe que la raiz del problema del segundo sistema es que la complejidad del software no crece linealmente con su tamaño sino mucho más rápido. Siendo la solución clásica limitar el número de formas en las cuales los subsistemas pueden inter-actuar. Este es el principio básico que hay detrás de las nuevas Arquitecturas Orientadas a Servicios

No obstante, yo creo que hay otra analogía útil. Microsoft ha estado praticando el estilo de la guerra relámpago hitleriana. Basado en concentrar una abrumadora cantidad de recursos bien pertrechados y organizados y literalmente pasar por encima del enemigo en cada batalla.
Esta estrategia funcionó bien en Europa, pero fue desastrosa en Stalingrado por la imposibilidad de la Luftwaffe para establecer un puente aéreo con la ciudad rusa que garantizase un suministro permanente durante el invierno.
¿Cómo se aplica esto a un proyecto de software? Bien, cuanto mayor es el proyecto mejores deben ser las herramientas de comunicación. Los bugs de un proyecto de 8 ó 10 meses-persona pueden controlarse con una hoja de cálculo. Para un proyecto de miles de meses-persona se requiere una compleja base de datos de requerimientos y defectos software.

Es sorprendente lo mucho que se ha escrito sobre la importancia de una buena especificación de requisitos e incluso sobre la programación como actividad social, y la escasa cantidad de materiales referentes a la metodología necesaria para comunicar dichos requisitos. Incluso vale la pena recordar el reciente informe de la NASA implicando el abuso del PowerPoint en el accidente del Columbia

Otra posible solución consiste en emplear un grupo de foco. El grupo de foco son 5 ó 10 programadores estrella que mantienen la misión del producto centrada en unos pocos aspectos esenciales y organizan el resto de las funcionalidades periféricas de menor importancia alrededor del núcleo básico de lo que se pretende construir. Los grupos de foco operan muy bien cuando ya existe un pequeño prototipo del nucleo que funciona y es estable, en parte porque el propio prototipo hace las veces de la especificación de requisitos. Esto es un consejo que creo haberle leído por primera vez a Bjarne Stroustrup en The Design and Evolution of C++ : “Un sistema grande y complejo que no ha evolucionado a partir de otro pequeño y simple no funciona y, además, es imposible arreglarlo para que funcione”.

Los partidarios del Software Libre han propuesto la táctica de la horda Mongola para solucionar el desafío de estabilizar grandes sistemas complejos. Nos lanzamos todos a reportar y corregir bugs y con miles y miles de personas contribuyendo seguro que solucionamos todos los problemas.
Yo no estoy muy convencido sobre este acercamiento de desarrollo en comunidad. Me gustan las cosas simples, y miles y miles de personas contribuyendo no es algo simple. Como sugería Ken Thompson en una entrevista a Computer Mag si el código lo toca todo el mundo de forma incontrolada al final se acaba convirtiendo en un spagetthi. El embarazo y parto de elefante que supuso Debian Sarge muestra que el modelo del bazar tampoco es la panacea para resolver el efecto del segundo sistema.
Cuando estuve en la LinuxWorld Expo en febrero de 2005 a Miguel de Icaza le introducíanen una presentación como “el dictador benévolo de Mono” lo cual permite intuir cómo se piensa incluso en las empresas de software libre que se debe organizar un proyecto de software.

En conclusión, tendremos que esperar ya poco para saber si Vista es el próximo milagro de la creación o un Frankenstein al que nadie sabe muy bien cómo habremos llegado.

Actualización: What did Microsoft learn from Vista? (Mary Jo Foley)

Comentarios
1 Carlos Rovira
26 septiembre 2005, 10:07

Buen, ya solo por la cantidad de tiempo y personas invertido, creo que Vista será o el Sistema Operativo panacea o no se exactamente a que están jugando en Redmon…

Me decanto por lo primero, pues quiero pensar que cuando un sistema se le da el tiempo necesario para que germine y crezca bien lo normal es que el resultado final sea un producto bueno y estable.

Ojala sea así.
2 Nacho
26 septiembre 2005, 15:45

Muy buen artículo, aunque me habría gustado poder conocer más sobre qué supuso que Allchin determinase que era necesario tirar todo lo hecho de Longhorn y comenzar de cero .
Aclaración: creo que hay datos algo incorrectos sobre la evolución de Windows. Creo que poco o nada tiene el 2000 de integración con el 98 (aunque parece un error habitual, debido a la nomenclatura), y que es “tan sólo” una revisión del NT. La verdadera integración de las dos ramas llegó con XP.
3 Juanjo Navarro
26 septiembre 2005, 16:21

Bueno, la versión 2000 fue la primera que integro el interface de windows 98 (en el nucleo de NT, eso sí). No se si hay mayor integración, pero los elementos del UI sí fueron integrados.
Acerca - Contacto - Información legal y técnica - Condiciones de uso - Noticias sobre el mundo del Desarrollo de Software.