[LUG.ro Mix] El apagado de Windows Vista
Omar Arino
lugro-mix@lugro.org.ar
Sun, 15 Jul 2007 13:50:29 -0300
Lean este traducción que encontré blogrolando por ahÃ:
http://blog.smaldone.com.ar/2006/11/26/el-apagado-de-windows-vista/
El apagado de Windows Vista
(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.
Blog de Javier Smaldone
--
Omar Arino