Boa noite meus queridos!
Hoje vemos a nona parte da tradução de “The Cathedral and the Bazaar”. No versículo de ontem vimos a oitava.
Mais usuários encontram mais bugs porque adicionar mais usuários adiciona mais maneiras diferentes de “estressar” o programa. Este efeito é amplificado quando os usuários são co-desenvolvedores. Cada um aborda a tarefa de caracterização de bugs com um conjunto de percepções e um conjunto de ferramentas analíticas ligeiramente diferentes, um ângulo diferente do problema. O “efeito Delphi” parece funcionar precisamente por causa dessa variação. No contexto específico de depuração, a variação também tende a reduzir a duplicação de esforços.
Portanto, adicionar mais beta-testers pode não reduzir a complexidade do bug “mais profundo” atual do ponto de vista do desenvolvedor, mas aumenta a probabilidade de que o kit de ferramentas de alguém seja correspondido ao problema de tal forma que o bug seja superficial para aquela pessoa.
Linus também se prepara para perdas. No caso de haver bugs sérios, a versão do kernel do Linux é numerada de tal forma que os usuários em potencial podem escolher entre executar a última versão designada como “estável” ou usar a tecnologia de ponta e arriscar erros para obter novos recursos. Essa tática ainda não é sistematicamente imitada pela maioria dos hackers do Linux, mas talvez deva ser; o fato de que qualquer escolha esteja disponível torna ambas mais atraentes. [HBS]
[HBS] A divisão entre as versões experimental e estável do Linux tem outra função relacionada, mas distinta, do risco de cobertura. A divisão ataca outro problema: a mortandade dos prazos Quando os programadores são mantidos em uma lista de recursos imutável e em uma data fixa, a qualidade sai pela janela e provavelmente há uma confusão colossal em andamento. Sou grato a Marco Iansiti e Alan MacCormack, da Harvard Business School, por me mostrarem evidências de que relaxar qualquer uma dessas restrições pode tornar o agendamento viável.
Uma maneira de fazer isso é determinar o prazo mas deixar a lista de recursos flexível, permitindo que os recursos caiam se não forem concluídos até o prazo final. Esta é essencialmente a estratégia do ramo de kernel “estável”; Alan Cox (o mantenedor do kernel estável) lança releases em intervalos regulares, mas não garante quando determinados bugs serão corrigidos ou quais recursos serão transferidos para o ramo experimental.
A outra maneira de fazer isso é definir uma lista de recursos desejada e entregá-la somente quando isso for feito. Esta é essencialmente a estratégia do ramo “experimental” do kernel. De Marco e Lister citaram pesquisas mostrando que essa política de agendamento (“me acorde quando terminar”) produz não apenas a mais alta qualidade, mas, em média, tempos de entrega mais curtos do que o agendamento “realista” ou “agressivo”.
Cheguei a suspeitar (a partir do início de 2000) que, em versões anteriores deste ensaio, eu subestimara seriamente a importância da política de “acordar-me quando é feito” para a produtividade e qualidade da comunidade de código aberto. A experiência geral com o lançamento acelerado do GNOME 1.0 em 1999 sugere que a pressão por um lançamento prematuro pode neutralizar muitos dos benefícios de qualidade que o código aberto normalmente confere.
Pode muito bem acontecer que a transparência do processo de código aberto seja um dos três fatores co-iguais de sua qualidade, juntamente com o agendamento “wake-up when it’s done” [acorde-me quando feito] e a auto-seleção do desenvolvedor.
Esta foi a 9ª parte da obra, segunda a décima. Fiquem com Deus, e bom domingo!
