¿Modelo de desarrollo chapuza? Ex-trabajadores de Vista dan pistas

Hace unos días, comenté un artículo magnífico sobre la inmensa, monumental chapuza que era el menú de apagar Windows Vista, con sus nueve opciones diferentes para apagar el ordenador, mas los botones (ver imagen). Pues bien, ahora resulta que el ex-programador de Micros~1 que se ocupó de implementarlo - y que ahora trabaja para Google - ha escrito en su blog como es posible que haya sucedido eso, como es posible funcionar tan mal, como es posible que, según el propio ex-programador, algo que debería llevar una semana diseñar, implementar y probarlo haya llegado a tardar más de UN AÑO. Y lo explica con todo lujo de detalles, haciendo del artículo una critica clara los procesos internos de Micros~1. Recomiendo su lectura. Un pequeño resumen y algunas curiosidades:

• Su equipo tenía un Mac al cual admiraban como paradigma de las interfaces sencillas y bien hechas (parece referirse a "físicamente", como si los diseñadores de la UI lo tuvieran ahí a propósito). No hace falta decir que Allchin se pasa el día diciendo que si Vista es el mejor sistema operativo del mundo, y el entorno Micros~1 lo repite continuamente. Jamás serán capaces de admitir la superioridad de Mac OS en el escritorio. Los Linuxeros al menos lo reconocemos (no hay más que ver gnome).


• Dice que su equipo era gente con talento, capaz, con buenas ideas. La receta para el éxito. Lo que confirma lo de siempre: Los programadores de Micros~1 no son especialmente malos o buenos, son programadores, como todos los demás. Es la gestión, los que mandan, los que crean el infierno.


• ...pero además de la gente encargada de hacer el trabajo, había un "manager", un "asistente de experiencias de usuario, 3 testers...un total de ocho personas que formaban el equipo básico para implementar el menú de apagado (supuestamente tambien harían alguna otra cosa como ocuparse del mismo menu en dispositivos embebidos y demás pero no mucho más; el menu de inicio era cosa de otros por ejemplo)


• Adicionalmente, su equipo tenía que mantener relaciones con el equipo encargado del menú de inicio, el kernel que implementaba la funcionalidad necesaria para apagar...adicionalmente existen hasta 6 capas de "managers" entre los equipos. En total, alrededor de 43 personas relacionadas, de las cuales 24 podían decir o hacer algo que influyera sobre el trabajo final. 24 personas para opinar sobre como diseñar la interfaz para apagar el ordenador.


• Cuando el programador que nos cuenta la historia se fue, despues de un año de trabajo, Vista no estaba lanzado, pero de todas maneras no se sabía como iba a acabar funcionando el tema de apagar el ordenador. El código total despues de un año era tan solo de alrededor de doscientas líneas de código. En realidad no hacía falta más, se trata de la interfaz encargada de apagar el ordenador: Unas pocas opciones mas el código encargado de ejecutar las llamadas pertinentes. No se trata del código encargado de apagar el ordenador, no, se trata del menu encargado de llamar al código encargado de apagar el ordenador. El código encargado de apagar es tarea del equipo del kernel. Estamos hablando de que su tarea era diseñar un menu, nada más, algo que debería tomar una semana a todo el equipo, sin escatimar en meticulosidad. ¿En que se había consumido el tiempo, entonces? Pues alrededor de cada 4 semanas el grupo del kernel o el de menu de inicio se quejaba de algo en la reunión semanal. Luego, en su propia reunión semanal, discutian durante 90 minutos sobre como ese cambio afectaba al menú de las 200 líneas. Hacían lo mismo en la reunión de la siguiente semana, a la siguiente, a la siguiente....y a la siguiente volvía a haber una reunión donde el kernel y/o los del menu de inicio se quejaban de algo. Vuelta a empezar. Así, un año.


• Un detalle muy curioso: El sistema de gestión de código. Resulta que como el número de programadores con necesidad de introducir sus cambios es muy elevado, no existe un único repositorio centralizado (lógico), la infraestructura no lo soportaría. Asi que el repositorio central es en realidad un repositorio de repositorios descentralizados que a su vez está dividido en repositorios. Un repositorio para cada grupo, vaya. Y los desarrolladores incluyen sus cambios en los "nodos" finales. Despues de un tiempo se integran en los repositorios superiores. Y despues de otro periodo, se integran en el repositorio central.


• El repositorio de este trabajador se ubicaba en una jerarquía de cuatro nodos, asi que los cambios tardaron entre uno y tres meses en llegar al repositorio central. Para más inri, los repositorios de los grupos con los cuales tenían que interactuar, el grupo del menú de inicio y el del kernel, estaban separados del suyo, no compartían ningún subrepositorio excepto el central. Consecuencia: Pasaban semanas hasta que se enteraba en qué direccion estaban yendo los programadores de esos grupos, semanas para descubrir los fallos. Chapuza total.

Reacción de Joel Spolsky al leer estos comentarios de este ex-trabajador - recordar que Joel fue programador del equipo de Excel en Microsoft -: "Every piece of evidence I've heard from developers inside Microsoft supports my theory that the company has become completely tangled up in bureaucracy, layers of management, meetings ad infinitum, and overstaffing." ("Todo lo que he escuchado de boca de trabajadores de Microsoft apoya mi teoría de que la compañía ha sido invadida por la burocracia, capas interminables de "managers", reuniones, exceso de trabajadores....")