Microsoft acusado de un proceso de desarrollo de Windows 10 fundamentalmente defectuoso

A estas alturas, todos somos conscientes del fiasco que ha sido el lanzamiento de la actualización de octubre de 10 de Windows 2018, pero probablemente ya olvidamos que la actualización de abril de 2018 también se retrasó debido a errores de última hora que causaron pantallas azules en algunas PC.

Ars Technica ha examinado más de cerca el desarrollo de Windows, y creen que el proceso de desarrollo de su sistema operativo de Microsoft fue defectuoso desde el principio, incluso hasta Windows 7.

Señalan que Microsoft tiene un proceso de escritura de código para nuevas características de solo unas pocas semanas, y luego pasa el resto del tiempo (de varios meses) integrando el software y luego corrigiendo errores antes del lanzamiento. Esto significó que se introdujo un software poco confiable y de mala calidad en la base de código de Windows 10, y si no se encuentran problemas, se entregará al usuario final.

Junto con un régimen de prueba ineficaz, en parte debido a que Microsoft despidió sus SDT en 2014 y asignó más responsabilidad a los desarrolladores para probar su propio código, y un proceso de Windows 10 Insider por parte de aficionados que no fue completo y que no entregó informes de errores profesionales, significó que más de una parte justa de los errores terminaron siendo enviados.

Ars Technica también confirmó que a los desarrolladores de Windows se les permitió integrar el código sin ninguna prueba, aunque con suerte, esta fue la excepción.

Pidieron un cambio en el proceso de desarrollo de Microsoft y pidieron que el nuevo software se probara bien antes de la integración utilizando técnicas modernas como las pruebas automatizadas, lo que significa que incluso las compilaciones de Insider tendrán un código bien probado y de alta calidad sin "problemas conocidos".

Ellos notan:

Una nueva característica puede ser inestable durante su desarrollo, pero antes de que esa característica pueda fusionarse con el código de producción, debe cumplir con una barra de calidad muy alta. En lugar del enfoque de Microsoft de "combinar los errores ahora, los corregiremos más tarde", el enfoque es garantizar que el código esté tan libre de errores como sea posible. antes se fusiona.

Ellos concluyen:

Adoptar el principio de que el código de Windows siempre debe tener calidad de envío, no "después de unos meses de reparación", sino "ahora mismo, en cualquier momento", sería un cambio enorme. Pero es necesario. Microsoft necesita estar en una posición en la que cada nueva actualización sea de calidad de producción desde el primer día; un mundo donde la actualización a la última y mejor versión es una obviedad, una elección que se puede tomar con confianza. Las actualizaciones de funciones no deben ser eventos, apenas percibidos por los usuarios.

Ars Technica mantiene al equipo Chrome de Google como una empresa que lo está haciendo bien, y con ChromeOS convirtiéndose en una opción cada vez más viable, Microsoft ciertamente no puede darse el lujo de perder más confianza por parte de los usuarios finales.

¿Qué piensan nuestros lectores? Háganos saber a continuación.