(Todavía me estoy riendo.) Hace un par de días leí un muy buen análisis sobre algunos errores en el diseño de la interfaz de Windows Vista, basado en el menú de “apagar el sistema” (que resulta tan flexible que confunde).
Ahora leo un artículo publicado por Moishe Lettvin, el mismísimo desarrollador de dicho menú. Y lo que dice es realmente para (perdón, pero sigo sin poder parar) revolcarse de la risa.
(A ver, me sereno un poco.) Primero, veamos de la monumental pieza de software que estamos hablando:
(Si, si, ¡son los dos botones y el menucito ese!)
A continuación, la traducción del artículo del programador. (A ver si se entiende de qué me río tanto.)
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 raison d’etre 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.
Mi conclusión
Risas aparte, la conclusiones que saco de este artículo son:
- Que la estructura (y la estupidez) burocrática de Microsoft es de lo más común hoy en día. Está de moda en perder el tiempo preparando, participando o comentando reuniones inútiles llenas de presentaciones y discursos vacíos (y armar estructuras organizativas ridículas por cada micro-proyecto). Parece ser que las principales herramientas de diseño de software en la industria son Microsoft Powerpoint, Microsoft Visio y Microsoft Project (¿será porque los diagramas no se cuelgan?).
- El sistema de manejo del source tree que utiliza Microsoft es más que aberrante. Esto denota un verdadero autismo. De tantas cosas que ha copiado (muchas de forma ilegal) esta empresa, me cuesta creer que nadie tenga dos dedos de frente como para mirar cómo manejan estas cosas proyectos enormes (y enormemente exitosos) de acceso público como Linux (y me refiero sólo al kernel).
Me parece que en esta situación se aplica perfectamente la Ley de Conway (enunciada en 1968):
Cualquier componente de software refleja la estructura organizacional que lo produjo.
Gracias de nuevo por traducir el texto. Que por cierto es genial, aun estoy llorando de la risa.