Segredos do WindowsQuem paga o pato

Raymond Chen

À medida que um projeto se aproxima de seu término, a equipe freqüentemente realiza um jogo informal conhecido como Quem paga o pato. Nesse jogo, as equipes “competem” para evitar serem responsáveis pela última alteração no produto, pois, em princípio, se não houvesse bug, o projeto poderia ser liberado um dia antes. (Isso raramente ocorre, mas é, apesar de tudo, a motivação do jogo.) A competição é puramente virtual – ninguém realmente mantém a pontuação e o “vencedor” logo é esquecido.

A não ser que você seja o vencedor.

Um dos membros seniores da equipe do Windows admitiu para mim que venceu duas vezes consecutivas nos primórdios do Windows. A segunda vez foi especialmente notável, pois a mudança foi feita após a produção ter sido iniciada. Foi necessário fazer um recall e reiniciar todo o processo de produção.

No entanto, uma tentativa de fazer com que ele vencesse pela terceira vez não foi bem-sucedida. A terceira tentativa acabou sendo a penúltima, em vez de última. A verificação final foi feita por outro colega que não só realizou a verificação final para o Windows 2000, mas então iniciou uma nova dinastia ao também fazer a verificação final para o Windows XP.

Uma das ironias do jogo Quem paga o pato é que freqüentemente as pessoas que contribuíram com sua eficiência (e, portanto, as pessoas que você menos esperaria) acabam ganhando. Veja bem, isso não é por que o código é inferior. Por estarem bem preparadas, elas estão em uma posição muito melhor para fazer a verificação final, mesmo que não seja em um componente pelo qual elas normalmente teriam responsabilidade.

Fazer uma verificação tardia é uma tarefa difícil, pois o isolamento que normalmente separa o desenvolvedor da equipe master não está mais presente. Em circunstâncias normais, uma verificação ocorreria da seguinte forma:

• Você faz a sua verificação no seu subprojeto.
• O laboratório de compilação do seu subprojeto trabalha na alteração durante a noite e entrega a compilação pela manhã.
• A equipe de teste do seu subprojeto analisa o código por uma semana ou mais antes de dar o OK para que a verificação seja liberada.

Dessa forma, é muito mais provável que, caso você tenha cometido erros, eles sejam detectados antes de fazer parte oficial do projeto. Alguns subprojetos são tão grandes que aplicam esse princípio recursivamente, criando subprojetos que verificam suas alterações independentemente, antes de serem liberados para o subprojeto maior ao qual pertencem.

Mas quando você está no jogo de encerramento do projeto e a equipe de gerenciamento de lançamento decide que você deve realizar a correção, as horas estão passando e não há tempo para o divertido processo de verificação de alteração de várias semanas. Em todas as fases do projeto, há desenvolvedores que compilam regularmente o projeto inteiro (não apenas seu subprojeto), desde a preparação do caminho para a criação de imagens de disco em um servidor particular de lançamento até a verificação de se as restrições da compilação foram atendidas. (Por exemplo, uma das coisas que eles fariam seria verificar se a imagem de CD não é muito grande para um CD!)

Se uma equipe se encontrar em uma situação em que precise fazer uma verificação de última hora, ela geralmente contará com o membro da equipe que estiver bem preparado – se essa pessoa não existir, a equipe então solicitará a assistência de alguém da equipe próxima que esteja bem preparado.

Nesse momento, ocorre um pequeno ciclo. A equipe fornece a alteração para o desenvolvedor bem preparado e ele cria as imagens de disco, verifica as restrições da compilação e direciona a equipe de teste para o servidor particular de liberação. Se a equipe de teste detectar um problema, a equipe de desenvolvimento apresentará uma nova solução e a passará ao desenvolvedor bem preparado, que reiniciará o ciclo.

Em outras palavras, o desenvolvedor bem preparado atua como um laboratório de compilação virtual, com um só membro, para essa equipe. Assim que todos estiverem satisfeitos, o desenvolvedor bem preparado fará a verificação. É por isso que aqueles que estão bem preparados acabam ganhando o jogo Quem paga o pato. Não é por eles estarem na raiz do problema, mas por estarem prontos para ajudar os que estão envolvidos no problema.

O site de Raymond Chen, The Old New Thing, e o livro homônimo (Addison-Wesley, 2007) tratam da história do Windows, da programação Win32 e da explosão de máquinas de café.