Este post clássico de Eric Lippert descreve, em detalhes excruciantes e dolorosos, exatamente quanto trabalho é necessário para adicionar um único ChangeLightBulbWindowHandleEx para uma base de código na Microsoft:
Um desenvolvedor para gastar cinco minutos implementando ChangeLightBulbWindowHandleEx. Um gerente de programa para escrever a especificação. Um especialista em localização para revisar a especificação quanto a questões de localizabilidade. Um especialista em usabilidade para analisar a especificação quanto a questões de acessibilidade e usabilidade. Pelo menos um desenvolvedor, um testador e um PM para fazer um brainstorming das vulnerabilidades de segurança. Um PM para adicionar o modelo de segurança à especificação. Um testador para escrever o plano de teste. Um líder de teste para atualizar o cronograma de testes. Um testador para escrever os casos de teste e adicioná-los à automação noturna. Três ou quatro testadores para participar de um bug bash ad hoc. Um redator técnico para escrever a documentação. Um revisor técnico para revisar a documentação. Um editor de texto para revisar a documentação. Um gerente de documentação para integrar a nova documentação ao corpo de texto existente, atualizar tabelas de conteúdo, índices etc. Vinte e cinco tradutores para traduzir a documentação e as mensagens de erro para todos os idiomas suportados pelo Windows. Os gerentes dos tradutores moram na Irlanda (idiomas europeus) e no Japão (idiomas asiáticos), ambos com grande diferença de horário em relação a Redmond, portanto, lidar com eles pode ser um problema logístico bastante complexo. Uma equipe de gerentes seniores para coordenar todas essas pessoas, preencher os cheques e justificar os custos para o vice-presidente.
Acho que, às vezes, os programadores se esquecem da quantidade de trabalho que é criar software em grandes empresas. O que pode parecer uma simples mudança de código de cinco linhas para nós, do lado de fora, talvez seja um trabalho de cinco semanas-homem quando o senhor leva em conta toda a sobrecarga de processo necessária. Estamos falando da Microsoft, mas isso não se limita a ela; é uma simples função de escala e público para todos os softwares comerciais.
Portanto, a pergunta óbvia: quem faz todas essas coisas para software de código aberto não comercial? A resposta, de acordo com um comentário de Raymond Chen no mesmo post, é “ninguém”:
Quem desenvolve os planos de teste para o software de código aberto? Quem atualiza as capturas de tela no guia do usuário e na ajuda on-line? E quem traduz a documentação para o polonês e o turco? Quem verifica se o recurso não viola a Lei dos Americanos com Deficiência ou as leis de privacidade alemãs? Na época em que eu trabalhava com Linux, a resposta era “Ninguém”. Não há plano de teste, não há guia do usuário impresso, a pouca documentação que existe está apenas em inglês e ninguém se preocupa em cumprir a ADA ou as leis de privacidade alemãs”. Talvez as coisas tenham mudado desde então.
Aqui está minha pergunta honesta: o software de código aberto precisa todo esse processo para ser bem-sucedido? A falta radical de bagagem de processos no desenvolvimento de software de código aberto não é uma fraqueza, mas, na verdade, uma vantagem evolutiva? O que falta ao software de código aberto em termos de processo formal é compensado dez vezes mais em ubiquidade e comunidade. Em outras palavras, se os Elbonianos têm tanta vontade de localizar, eles mesmos podem assumir esse esforço. Enquanto isso, os desenvolvedores têm mais tempo para implementar recursos que satisfaçam a maior base de clientes, em vez de passar por montanhas de processos para cada minúscula alteração de código de cinco linhas.
As grandes empresas de software comercial são prejudicadas por seus próprios processos??
Se o senhor recompensar e promover abertamente as pessoas por matarem o trabalho, lamentando o risco, o custo dos testes e o impacto da localização de cada recurso e interrogando uma solicitação de alteração de design como se fosse Dan Brown acorrentado na frente de um papa de olhos selvagens e com um hotpoker na mão, bem, todos vão pegar forquilhas e pular para o vagão do “No can do! Não é possível enviar!”.
Isso me faz pensar em quantas reuniões sobre recursos eu já tive e em como uma pequena porcentagem desses recursos chegou a ser lançada. Não que todo recurso seja uma boa ideia, mas, às vezes, é quase digno de despertar o fato de um recurso ser realmente enviado. Que Eeyore: “Ah, não. Agora temos que dar suporte a ele. Suponho que uma solicitação de hotfix chegará a qualquer momento…”
Com muita frequência, realmente parece que o software da Microsoft foi projetado por Eeyore.
Nesse caso, o pássaro representa os recursos que encantam os clientes.