Boa noite povo!
No versículo anterior vimos a sétima parte da tradução de “The Cathedral and the Bazaar”. Hoje vemos a oitava.
A Lei de Linus pode ser reformulada como “Depuração é paralelizável”. Embora a depuração exija que os depuradores se comuniquem com algum desenvolvedor de coordenação, ela não exige uma coordenação significativa entre depuradores. Assim, ele não é vítima da mesma complexidade quadrática e dos custos de gerenciamento que tornam a adição de desenvolvedores problemática.
Na prática, a perda teórica de eficiência devido à duplicação de trabalho por depuradores quase nunca parece ser um problema no mundo Linux. Um efeito de uma política de “release early and often” [lance antecipada e frequentemente” é minimizar essa duplicação propagando rapidamente as correções fornecidas [JH].
Brooks (o autor de The Mythical Man-Month) até fez uma observação negativa relacionada a isso: “O custo total de manutenção de um programa amplamente utilizado é tipicamente 40% ou mais do custo de desenvolvê-lo. Surpreendentemente, esse custo é fortemente afetado pelo número de usuários. Mais usuários encontram mais bugs.” [ênfase adicionada].
[JH] John Hasler sugeriu uma explicação interessante para o fato de que a duplicação de esforços não parece ser um empecilho para o desenvolvimento de código aberto. Ele propõe o que chamarei de “Lei de Hasler”: os custos do trabalho duplicado tendem a ser escalonados sub-quadraticamente com o tamanho da equipe – isto é, mais lentamente do que a sobrecarga de planejamento e gerenciamento que seria necessária para eliminá-los.
Esta alegação, na verdade, não contradiz a lei de Brooks. Pode ser o caso de sobrecarga de complexidade total e vulnerabilidade a bugs escalar com o quadrado do tamanho da equipe, mas que os custos de trabalho duplicado são, no entanto, um caso especial que escala mais lentamente. Não é difícil desenvolver razões plausíveis para isso, começando pelo fato indubitável de que é muito mais fácil chegar a um acordo sobre limites funcionais entre códigos de desenvolvedores diferentes que vão evitar a duplicação de esforços do que evitar os tipos de interações ruins não planejadas em todo o sistema que constituem a base da maioria dos bugs.
A combinação da Lei de Linus e da Lei de Hasler sugere que existem três regimes de tamanho crítico em projetos de software. Em projetos pequenos (eu diria um para no máximo três desenvolvedores) não é necessária uma estrutura de gerenciamento mais elaborada do que escolher um programador líder. E há um intervalo intermediário acima daquele em que o custo do gerenciamento tradicional é relativamente baixo, de modo que o benefício de evitar a duplicação de esforços, o rastreamento de erros e a pressão para ver que os detalhes não sejam desprezados são realmente positivos.
Acima disso, no entanto, a combinação da Lei de Linus e da Lei de Hasler sugere que há uma ampla gama de projetos em que os custos e problemas da gestão tradicional aumentam muito mais rapidamente do que o custo esperado da duplicação de esforços. O menor desses custos é a incapacidade estrutural de aproveitar o efeito de muitos olhos, que (como vimos) parece fazer um trabalho muito melhor do que o gerenciamento tradicional, garantindo que os bugs e os detalhes não sejam negligenciados. Assim, no caso de grandes projetos, a combinação dessas leis efetivamente leva a compensação líquida da administração tradicional a zero.
Terminada a 8ª parte da obra, amanhã a nona. Abraços!
