Boa tarde povo!
Não pude postar ontem e na sexta. Voltando hoje então para a continuação da tradução de “The Cathedral and the Bazaar”. Vimos no versículo anterior a parte 24, hoje vemos a vigésima quinta.
Até agora, o gerenciamento de desenvolvimento convencional parece atualmente uma aposta ruim contra o código aberto em dois pontos (alocação de recursos, organização) e como se estivesse ‘fazendo hora extra’ em relação a um terceiro (motivação). E o pobre gerente convencional cercado não obterá nenhum socorro da questão do monitoramento; o argumento mais forte da comunidade de código aberto é que a revisão por pares descentralizada supera todos os métodos convencionais para tentar garantir que os detalhes não sejam esquecidos.
Podemos salvar as metas definidas como justificativa para a sobrecarga do gerenciamento de projetos de software convencional? Possivelmente; mas, para isso, precisaremos de boas razões para acreditar que os comitês de gestão e os roteiros corporativos são mais bem-sucedidos na definição de metas dignas e amplamente compartilhadas do que os líderes de projeto e anciãos tribais que desempenham o papel análogo no mundo do código aberto.
Em face disso, é um caso bastante difícil de resolver. E não é tanto o lado de código aberto da balança (a longevidade do Emacs, ou a capacidade de Linus Torvalds de mobilizar hordas de desenvolvedores com a conversa de “dominação do mundo”) que dificulta. Pelo contrário, é o horror demonstrado dos mecanismos convencionais para definir os objetivos dos projetos de software.
Um dos teoremas populares mais conhecidos da engenharia de software é que 60% a 75% dos projetos de software convencionais nunca são concluídos ou são rejeitados pelos usuários pretendidos. Se esse intervalo for quase verdadeiro (e eu nunca conheci um gerente de qualquer experiência que o conteste), mais projetos do que não estão sendo direcionados a objetivos que (a) não são realisticamente atingíveis ou (b) simplesmente errados.
Isso, mais do que qualquer outro problema, é a razão pela qual, no mundo atual da engenharia de software, a própria frase “comitê de gerenciamento” provavelmente envia arrepios na espinha do ouvinte – mesmo (ou talvez especialmente) se o ouvinte for gerente. Os dias em que apenas os programadores se apegaram a esse padrão já passaram; Os desenhos animados de Dilbert estão sobre as mesas dos executivos agora.
Nossa resposta, então, ao gerente tradicional de desenvolvimento de software, é simples – se a comunidade de código aberto realmente subestimou o valor do gerenciamento convencional, por que tantos de vocês demonstram desprezo pelo seu próprio processo?
Mais uma vez, o exemplo da comunidade de código aberto aprimora essa questão consideravelmente – porque nos divertimos fazendo o que fazemos. Nosso jogo criativo tem acumulado sucessos técnicos, de participação de mercado e de participação mental a um ritmo espantoso. Estamos provando não apenas que podemos fazer um software melhor, mas que a alegria é um ativo.
Dois anos e meio após a primeira versão deste ensaio, o pensamento mais radical que posso oferecer para encerrar não é mais a visão de um mundo de software dominado por código aberto; afinal, isso parece plausível para muitas pessoas sóbrias de terno nos dias de hoje.
Em vez disso, quero sugerir o que pode ser uma lição mais ampla sobre software (e provavelmente sobre todo tipo de trabalho criativo ou profissional). Os seres humanos geralmente gostam de uma tarefa quando ela cai em uma espécie de zona de desafio ideal; nem tão fácil a ponto de ser entediante, nem muito difícil de alcançar. Um programador feliz é aquele que não é subutilizado nem sobrecarregado com objetivos mal formulados e fricção estressante no processo. Prazer prevê eficiência.
Relacionar-se com o seu próprio processo de trabalho com medo e repulsa (mesmo da maneira irônica e deslocada sugerida pela suspensão dos desenhos animados de Dilbert) deve, portanto, ser considerado em si um sinal de que o processo falhou. Alegria, humor e diversão são, de fato, ativos; não foi principalmente pela aliteração que escrevi sobre “hordas felizes” acima, e não é mera brincadeira que o mascote do Linux seja um pinguim fofinho e neotênico.
Pode acontecer que um dos efeitos mais importantes do sucesso do código aberto seja nos ensinar que brincar é o modo de trabalho criativo economicamente mais eficiente.
Terminado o versículo de hoje, volto amanhã com a vigésima sexta parte. Abraço!
