Lisandro Pardo
Hotfixes que no se instalan. Errores que borran archivos personales. Ciclos de actualización demorados. Hardware que sencillamente no funciona. No tiene sentido negarlo: El control de calidad en Microsoft se cayó a pedazos, un hecho reflejado en los múltiples problemas que ha sufrido Windows 10. ¿A qué se deben estas fallas? El youtuber Jerry Berg, mucho mejor conocido como Barnacules Nerdgasm, trabajó quince años para el gigante de Redmond, y compartió detalles jugosos sobre los procesos de evaluación que Microsoft abandonó, y los reemplazos que utiliza hoy.
Windows 10. En lo personal me encantaría decir que trabajamos y jugamos «con» Windows 10, pero cuatro años después estoy obligado a admitir que trabajamos y jugamos «a pesar» de Windows 10. Cada martes de parches viene acompañado con una plegaria pidiendo que Microsoft no quiebre nada durante el proceso de actualización, y siendo sincero, no creo que las cosas hayan mejorado tanto. La red está repleta de usuarios que describen (¡diariamente!) sus problemas con el sistema operativo, y los foros oficiales de Microsoft equivalen a un desierto de sal.
La pregunta de fondo es… ¿por qué? ¿Por qué llegamos a esto? ¿Por qué sacrificar la relativa estabilidad de Windows 7, en favor de un sistema operativo transformado en «servicio» que hace agua por todas partes? Para conocer la respuesta es necesario el conocimiento de alguien que haya recorrido las trincheras de Microsoft en el pasado, y ese alguien es Jerry Berg, o Barnacules Nerdgasm en YouTube. Con 15 años de experiencia acumulada en Redmond, esto fue lo dijo:
En una época, Microsoft tenía a su disposición un equipo entero de testers dedicados pura y exclusivamente a evaluar el sistema operativo. Ese equipo a su vez se dividía en grupos que representaban a una rama o un build específico. En sus pruebas había un alto nivel de automatización, pero estos grupos se reunían diariamente con el objetivo de intercambiar ideas y determinar si una pieza de código estaba lista o no para su upstream. Además, las pruebas se llevaban a cabo «sobre el metal», o sea en hardware real, y bajo miles de configuraciones, bastante exóticas en algunos casos.
Hasta allí todo suena muy bien, pero el problema es que llegó la gran purga de 2014, seguida por otra ronda de despidos en 2015, y este equipo de hardware básicamente desapareció, siendo reemplazado por el equipo encargado de testear a Windows Phone. En parte, los despidos estuvieron asociados a la consolidación de las tres grandes secciones de Microsoft (Windows, Windows Phone y Xbox) en una sola, pero la historia no termina allí: El hardware real fue reemplazado por entornos virtuales.
Si bien estamos de acuerdo en que una buena parte de las funciones de un sistema operativo pueden ser exploradas por la vía virtual, la idea aquí es cazar bugs (raros y comunes por igual), y la virtualización no posee la diversidad suficiente. Microsoft introdujo el concepto de self-host, de modo tal que sus propios empleados pasaron a ser beta testers. Si encontraban un bug sería imposible para ellos ignorarlo, porque los volvería locos. Sin embargo, el self-host también fue desplazado, y ahora todo depende de la telemetría.
Así es, la telemetría de los builds de Windows Insider, y de las versiones estándar de Windows 10. Ahora, Barnacules destaca que son muy pocos los usuarios de Windows Insider que envían reportes, y que la telemetría en sí es muy limitada frente a otros recursos clásicos como los minidumps (que tampoco quedan libres de problemas). Los desarrolladores de Microsoft deben trabajar con una base de datos de bugs, combinar la telemetría que reciben, crear el fix, y hacer el push a las imágenes Insider para comprobar si funciona, o si causa otros problemas.
Barnacules también dedica un momento a explorar el cambio de estrategia en la distribución de updates mayores de Windows 10. En un principio, todos recibían el mismo build, pero después de algunos incidentes catastróficos (con pérdida de información personal incluida), se optó por el «rollout». En resumen, toda la estructura de pruebas en Microsoft es débil, con Insiders y usuarios finales transformados en beta testers. ¿La sugerencia de Barnacules? Un poco de la vieja esencia (testers de carne y hueso con hardware real) y mayor comunicación con los usuarios para casos críticos, incluyendo el pedido de fulldumps (acompañado de alguna recompensa, porque el envío de fulldumps es una pesadilla).
