Ben Collins-Sussman em insegurança do programador:
O que o senhor faz quando alguém aparece em um projeto de código aberto com um novo recurso gigantesco que levou meses para ser escrito? Quem tem tempo para revisar milhares de linhas de código? E se houve uma decisão de projeto ruim tomada no início do processo, faz sentido apontar isso? Lançar bombas de código nas comunidades raramente é bom para o projeto: a equipe é forçada a rejeitá-lo completamente ou a aceitá-lo e lidar com uma bolha gigante e opaca que é difícil de entender, alterar ou manter. Isso move o projeto decididamente em uma direção sem muita discussão ou consenso.
E, no entanto, sempre sou reunindo histórias que apontam para o fato de que os programadores não querem escrever código às claras. Os programadores não querem que seus colegas vejam erros ou falhas. Eles querem trabalhar em particular, em uma caverna, e depois lançar o código “perfeito” em sua comunidade, como se nenhum erro tivesse sido cometido.
Não acho que seja tanto arrogância quanto medo de passar vergonha. Em vez de pensar na programação como uma atividade inerentemente social, a maioria dos programadores parece tratá-la como uma arena de heroísmo pessoal e fará de tudo para proteger esse mito. Eles não se importam em compartilhar códigos, desde que se apresentem como infalíveis, ao que parece. Talvez seja apenas a natureza humana.
Ben está falando sobre desenvolvimento de código aberto, mas esse antipadrão também existe no desenvolvimento de software comercial. O mesmo fenômeno está documentado no livro de 1995 de Jim McCarthy Dynamics of Software Development (Dinâmica do desenvolvimento de software). Ela é apresentada como Regra nº 30: Não fique no escuro.
O senhor precisa gerenciar a granularidade das tarefas de desenvolvimento de forma a obter resultados visíveis em intervalos curtos. Em nosso grupo, discutimos sobre o tamanho dos intervalos: cinco dias, dez dias, três semanas? Em nosso mundo, três semanas é o fim da linha.
Não sei o que é apropriado para o seu mundo, mas queremos que os membros da equipe tenham contratos com as outras partes da equipe para que eles apareçam com bastante frequência com componentes visíveis. Quando alguém aparece e a entrega não está concluída, ficamos sabendo imediatamente. Sabemos que esta semana atrasamos um dia. Vale a pena saber isso, muito melhor do que chegar ao final do projeto e constatar: “Ah, perdemos seis meses!” Nesse ponto, já é tarde demais para se preocupar em contar o quanto o senhor se atrasou.
A regra nº 30 é seguida diretamente por uma regra relacionada, a regra nº 31: Cuidado com um homem em uma sala.
Os desenvolvedores especializados que se trancam em um quarto, que ficam no escuro por longos períodos, são um anátema para o envio de um software excelente dentro do prazo. Por mais brilhante que seja um desenvolvedor, não lhe dê uma tarefa importante a menos que ele compreenda e aceite o tipo de programa de desenvolvimento que o senhor pretende executar. O desenvolvedor brilhante deve ser capaz de atuar em uma equipe, tornando seu trabalho visível em incrementos modestos e submetendo-o a um exame minucioso à medida que amadurece. Algumas pessoas acham isso intolerável e, embora exista uma função para pessoas com essa disposição no mundo do software, não é como parte de uma equipe dedicada a enviar um software excelente dentro do prazo.
É mais fácil lidar com isso no local de trabalho, porque normalmente o senhor tem algum tipo de gerenciamento de projeto (teoricamente) racional em vigor e todos trabalham sob o mesmo teto. É efetivamente impossível ficar no escuro se o senhor estiver praticando qualquer forma de desenvolvimento ágil de software. Por exemplo, Ron Jeffries pegou emprestado esse conceito do livro de Jim McCarthy e o codificou na tradição da programação extrema. As tarefas são sempre divididas em fatias para que caibam em uma única iteração, e o senhor nunca permite que elas se espalhem por várias iterações. O senhor sempre terá algo para mostrar no final de cada iteração. O senhor não pode ficar no escuro sem abandonar o projeto ou, talvez, seu emprego.
Um projeto de código aberto é um animal muito diferente. É um conjunto heterogêneo de voluntários amplamente distribuídos e pouco acoplados. Não há nenhum gerente de projeto respirando no seu pescoço, pedindo que você divida seu trabalho em incrementos curtos e compartilháveis. O risco de ficar no escuro é grande. O ônus da prova recai sobre os desenvolvedores individuais, não apenas para tornar seu trabalho no projeto visível em incrementos modestos, mas também para superar sua insegurança de código e compartilhar seu código em andamento com outras pessoas que trabalham no projeto. Como o senhor espera que seus colegas programadores o levem a sério se o senhor não lhes mostra regularmente o código? Essa é a única forma de moeda que importa em um projeto de código aberto.
Não fique no escuro. Não seja aquele cara na sala. Esconder seu código até que ele esteja “pronto” pode parecer mais seguro, mas não é. Compartilhar seu código em andamento com seus colegas de trabalho é assustador, muito menos com o mundo, mas isso também resulta em feedback e comunicação que melhorarão seu código e o aproximarão do projeto em que está trabalhando. E não é por isso que todos nós escrevemos código, em primeiro lugar?