Desarrollando el apagado de Windows Vista

El siguiente es un articulo escrito originalmente por Moishe Lettvin, el desarrollador del menú de inicio de Windows Vista, en el que nos cuenta cuánto tiempo demoró desarrollar dicho menú, y como fue el proceso. Uno pensaría que, ya que básicamente lo que hacen en Microsoft es copiar productos exitosos y «mejorarlos», pues el proceso de desarrollo de sus productos sería poco engorroso y efectivo. Realmente sorprendente la forma en que trabajan en Microsoft.

La porquería del apagado de Windows

Trabajé en Microsoft unos 7 años en total, desde 1994 hasta 1998 y desde 2002 a 2006.

El año más frustrante de los siete fue el que pasé trabajando en Windows Vista, que por aquellas épocas se llamaba Longhorn. Pasé un año completo trabajando en una función que debería haber sido diseñada, implementada y verificada en una semana. Para mi feliz sorpresa (donde «feliz» es el freude en schadenfreude), Joel Spolsky escribió un artículo sobre mi función.

Trabajé en el equipo «Windows Mobile PC User Experience». El mismo fue parte de Longhorn desde un punto de vista relativo a sus funciones, pero organizacionalmente era parte del grupo Tablet PC. Para encontrar un gerente común al resto de las personas con las que necesitaba trabajar, había que subir 6 o 7 niveles desde mi posición en el organigrama.

La razón de ser de mi equipo era: mejorar la experiencia de los usuarios en laptops, notebooks y PCs ultra-móviles. Lo suficientemente noble. Por supuesto el equipo Windows Shell, con cuyo código tenía que perder el tiempo para cumplir con mi pequeño trabajo, tenía su propio eslogan, que podía o no intersecar al nuestro.

Mi equipo tenía a un muy talentoso diseñador de IU (interfaz de usuario) y mi función particular tenía un director de proyecto bueno y testarudo, con ideas sólidas sobre experiencia de usuario. Teníamos una Mac, a la que tomamos como parangón de IU simple. Por supuesto, el equipo del shell también tenía algunos grandes deiseñadores de IU y muchos directores de proyectos buenos y testarudos que valoraban (asumo) la simplicidad y cosas por el estilo. Quizás también tenían una Mac.

Además de nuestro excelente diseñador de IU y nuestro director de proyecto bueno y testarudo, teníamos un experto en asistencia al usuario, un equipo de verificadores, varias capas de gestión y a mí, escribiendo código.

Asi es que, solamente en mi equipo, está es la gente que asistió a cada reunión de planificación sobre esta función:

• 1 director de proyecto
• 1 desarrollador
• 1 líder de desarrollo
• 2 verificadores
• 1 líder de verificación
• 1 diseñador de IU
• 1 experto en experiencia de usuario

8 personas en total.

Las reuniones de planificación ocurrieron cada semana, durante todo el año en que trabajé en Windows.

Además de lo anterior, teníamos dependencias con el equipo del shell (los muchachos que escribieron, diseñaron y verificaron el resto del menú Inicio), y con el equipo del kernel (quienes prometieron entregar funciones para hacer la IU de apagado tan clara y simple como queríamos). La parte más importante del equipo del shell era más o menos del mismo tamaño que nuestro equipo, como así también el equipo del kernel.

Esto nos arroja una estimación conservadora de 24 personas involucradas en esta función. Además, cada equipo de 8 estaba separado por 6 capas de gestión de los líderes, así que agreguémoslos también, lo que nos arroja 24 + (6 * 3) + 1 (el gerente compartido) 43 personas con voz en esta función. Veinticuatro de ellos estaban conectados cercanamente con el código, y de esos veinticuatro había exactamente cero con la última palabra sobre cómo funcionaría. En algún lado entre los otros 17 había alguien que sí tenía la última palabra, pero nunca tuve idea de quién era, ya que hasta el momento en que dejé el equipo (después de un año), aún no se había tomado la decisión de cómo debería trabajar esta función.

Dicho sea de paso, «función» es una palabra muy fuerte; una descripción más acertada sería «menú». Enserio. En el momento en que dejé el equipo, el código que había escrito para esta «función» fue de unos cientos de líneas, de muy buena calidad.

Pero así es como funcionaba el proceso de diseño: aproximadamente cada 4 semanas, en nuestra reunión semanal, nuestro director de proyecto decía: «el equipo del shell está en desacuerdo con cómo se ve/se siente/trabaja esto» y/o «el equipo del kernel ha decidido incluir/no incluir alguna funcionalidad que nos permite/impide hacer cierta cosa en particular». Y entonces en nuestra reunión semanal se pasaba aproximadamente 90 minutos discutiendo cómo nuestra función (menú) debería verse basandose en esta «nueva» información. Luego, en nuestra siguiente reunión semanal, pasábamos otros 90 minutos argumentando sobre el diseño, luego en nuestra próxima reunión semanal hacíamos lo mismo y en nuestra próxima reunión semanal llegábamos a algún acuerdo… justo a tiempo para recibir más información faltante del equipo del shell o del kernel, y comenzar con el proceso completo nuevamente.

También me gustaría bosquejar cómo la codificación real (lo que eso sea) funciona en el equipo Windows.

En los pequeños proyectos de programación existe un repositorio de código centralizado. Los «build» (compilación de todo el sistema) se realizan generalmente a diario, desde este repositorio central. Los programadores hacen sus cambios en este repositorio a medida que van trabajando, así el «build» diario es una instantánea bastante buena del estado actual del producto.

En Windows, el modelo se rompe simplemente porque hay tantos desarrolladores para acceder a un repositorio central (entre otros problemas, la infraestructura no lo soporta). Por lo tanto, Windows tiene un árbol de repositorios: los desarrolladores realizan los cambios en los nodos, y periodicamente estos son integrados un nivel hacia arriba en la jerarquía. Con una periodicidad distinta, los cambios son integrados desde la raíz del árbol hacia los nodos. En Windows, el nodo en que yo estaba trabajando estaba a 4 niveles de la raíz. La periodicidad de la integración decaía exponencialmente e impredeciblemente a medida que se acercaba a la raíz, al punto tal que a mi código le tomaba entre 1 y 3 meses en llegar a la misma, y algún múltiplo de eso en llegar hasta los otros nodos. Hay que destacar también que el único nodo común entre mi equipo, el equipo del shell y el equipo del kernel era la raíz.

Por lo tanto, además del problema anterior con la toma de decisiones, cada equipo no tenía idea de lo que otro equipo estaba haciendo realmente hasta que pasaban semanas.

El resultado final de todo esto es lo que se entregó finalmente: el mínimo común denominador, la opción más simple y menos controvertida.

No se qué tanto del resto de Vista terminó como esto. Creo (en realidad, espero) que mi equipo haya sido un caso patológico. Desafortunadamente es uno visible.

Ya no quiero trabajar en Microsoft! Que decepción…
Artículo Original: Moblog
Artículo Traducido: Blog de Javier Smaldone