O livro Producing Open Source Software: How to Run a Successful Free Software Project (Produzindo software de código aberto: como executar um projeto de software livre bem-sucedido) é um referência fantástica para qualquer pessoa envolvida em um projeto de software – quer o senhor esteja à frente do projeto ou não.
Além da edição em árvore morta, o livro está disponível em um formato livre de código aberto apropriado em o site oficial. O livro inteiro é excelente e vale a pena ser lido com atenção, mesmo que o senhor pense em código aberto é comunismo.
Meu capítulo favorito é o capítulo sobre comunicação. Embora seja importante em qualquer projeto de software, a comunicação é especialmente vital em projetos de código aberto, que são “desconcertantemente diversos, tanto em termos de público quanto de mecanismos de comunicação”. Uma armadilha específica dos projetos de código aberto é que, se o senhor não gerenciar o projeto com cuidado, pode tender a atrair desenvolvedores que estão mais interessados em discutir do que em escrever código. É um problema sutil, mas pernicioso: a comunicação deu errado.
Embora a discussão possa se desviar em qualquer tópico, a probabilidade de se desviar aumenta à medida que a dificuldade técnica do tópico diminui. Afinal, quanto maior a dificuldade técnica, menos participantes conseguem realmente acompanhar o que está acontecendo. Aqueles que conseguem são provavelmente os desenvolvedores mais experientes, que já participaram de tais discussões milhares de vezes antes e sabem que tipo de comportamento provavelmente levará a um consenso com o qual todos podem conviver.
Assim, o consenso é mais difícil de ser alcançado em questões técnicas que são simples de entender e sobre as quais é fácil ter uma opinião, e em tópicos “suaves” como organização, publicidade, financiamento, etc. As pessoas podem participar dessas discussões para sempre, porque não há qualificações necessárias para fazê-lo, não há maneiras claras de decidir (mesmo depois) se uma decisão foi certa ou errada e porque simplesmente esperar mais do que os outros debatedores às vezes é uma tática bem-sucedida.
O princípio de que a quantidade de discussão é inversamente proporcional à complexidade do tópico existe há muito tempo e é conhecido informalmente como o Efeito Bikeshed.
Tivemos dificuldades com isso no Stack Overflowtambém. As perguntas mais amplas e flexíveis tendem a despertar muito mais interesse e atenção do que as perguntas técnicas e restritas sobre codificação, para as quais o site foi originalmente planejado. Fizemos ajustes, mas esse é um aspecto inevitável da dinâmica de grupo. Quem estamos enganando? É divertido discutir de que cor o bicicletário deve ser pintado. Todos têm uma opinião sobre seu esquema de cores favorito.
O que muitas pessoas não percebem é que o efeito bikeshed é, de fato, uma forma de procrastinação. E isso pode sugar os desenvolvedores altamente técnicos, assim como todos os outros.
Os psicólogos entregaram questionários a um grupo de estudantes e pediram que eles respondessem por e-mail em três semanas. Todas as perguntas tinham a ver com tarefas bastante mundanas, como abrir uma conta bancária e manter um diário, mas cada estudante recebeu instruções diferentes para responder às perguntas. Alguns pensaram e escreveram sobre o que cada atividade implicava sobre características pessoais: que tipo de pessoa tem uma conta bancária, por exemplo. Outros escreveram simplesmente sobre os detalhes de cada atividade: falar com um funcionário do banco, preencher formulários, fazer um depósito inicial e assim por diante. A ideia era fazer com que alguns alunos pensassem de forma abstrata e outros de forma concreta. Então os psicólogos esperaram. E, em alguns casos, esperaram e esperaram. Eles registraram todos os tempos de resposta para ver se havia uma diferença entre os dois grupos e, de fato, houve uma diferença significativa.
Os resultados, relatados na Psychological Science, uma revista da Association for Psychological Science, foram muito claros. Mesmo que todos os alunos estivessem sendo pagos após a conclusão, aqueles que pensaram nas perguntas de forma abstrata tinham muito mais probabilidade de procrastinar e, na verdade, alguns nunca chegaram a fazer o trabalho. Em contrapartida, aqueles que se concentraram em como, quando e onde realizar a tarefa enviaram suas respostas por e-mail muito mais cedo, o que sugere que eles se lançaram diretamente na tarefa em vez de adiá-la.
Esse é um dos motivos pelos quais os senhores Estou tão desanimado com os astronautas da arquitetura. Acho que a quantidade de discussão sobre um recurso de software é inversamente proporcional ao seu valor. É claro que é preciso ter alguma discussão inicial para definir sua direção, mas quanto mais cedo o senhor puder se afastar das abstrações aéreas e se dedicar aos detalhes do construir a maldita coisaquanto melhor o senhor – e seu projeto – se sairão.
Em outras palavras, o que é a coisa mais difícil que o senhor tem de fazer todos os dias? Decidir o que ignorar, para que o senhor possa parar de procrastinar e fazer as coisas. Da próxima vez que se sentir envolvido em uma discussão prolongada sobre bikeshed, pense: o senhor não deveria estar construindo algo em vez disso?