Microsoft acusada de um processo de desenvolvimento do Windows 10 fundamentalmente falho

Até agora, todos estamos cientes do fiasco que foi o lançamento da atualização do Windows 10 de outubro de 2018, mas provavelmente já esquecemos que a atualização de abril de 2018 também foi atrasada devido a bugs tardios que causaram telas azuis em alguns PCs.

A Ars Technica deu uma olhada mais de perto no desenvolvimento do Windows, e eles acreditam que o processo da Microsoft de desenvolver seu sistema operacional foi falho desde o início, até o Windows 7.

Eles observam que a Microsoft tem um processo de realmente escrever código para novos recursos de apenas algumas semanas e, em seguida, passar o resto do tempo (de vários meses) integrando o software e corrigindo bugs antes do lançamento. Isso significava que um software não confiável e de baixa qualidade foi introduzido na base de código do Windows 10 e, se os problemas não forem encontrados, entregue ao usuário final.

Juntamente com um regime de testes ineficaz, em parte devido à Microsoft disparar seus SDTs em 2014 e colocar mais responsabilidade nos desenvolvedores para testar seu próprio código, e um processo Windows 10 Insider por amadores que não era abrangente e que não entregava relatórios de bugs profissionais, significava que mais do que um quinhão de bugs acabou sendo enviado.

A Ars Technica também confirmou que os desenvolvedores do Windows foram autorizados a integrar o código sem nenhum teste, embora, esperançosamente, essa tenha sido a exceção.

Eles pediram uma mudança no processo de desenvolvimento da Microsoft e pediram que o novo software fosse bem testado antes da integração usando técnicas modernas, como testes automatizados, o que significa que mesmo as compilações do Insider terão código bem testado e de alta qualidade sem “problemas conhecidos”.

Eles observam:

Um novo recurso pode ser instável durante seu desenvolvimento, mas antes que esse recurso possa ser mesclado no código de produção, ele precisa atender a um padrão de qualidade muito alto. Em vez da abordagem da Microsoft de “mesclar os bugs agora, vamos corrigi-los mais tarde”, a abordagem é garantir que o código seja o mais livre de bugs possível. antes ele fica mesclado.

Eles concluem:

Adotar o princípio de que o código do Windows deve sempre ter qualidade de envio – não “após alguns meses de correção”, mas “agora, a qualquer momento” – seria uma mudança enorme. Mas é um necessário. A Microsoft precisa estar em uma posição em que cada nova atualização tenha qualidade de produção desde o primeiro dia; um mundo onde a atualização para a versão mais recente e melhor é um acéfalo, uma escolha que pode ser tomada com confiança. As atualizações de recursos não devem ser eventos, pouco notadas pelos usuários.

A Ars Technica mantém a equipe do Google Chrome como uma empresa que está fazendo certo, e com o ChromeOS se tornando uma opção cada vez mais viável, a Microsoft certamente não pode perder mais confiança dos usuários finais.

O que nossos leitores pensam? Deixe-nos saber abaixo.