Cargo Cult Software Engineering
In The South Seas there is a cargo cult of people. Durante a guerra eles viram aviões com muitos bons materiais, e eles querem que a mesma coisa aconteça agora. Então eles dispostos a fazer as coisas como pistas, para colocar incêndios ao longo dos lados das pistas, para fazer uma cabana de madeira, por um homem para se sentar, com dois pedaços de madeira em sua cabeça para fones de ouvido e barras de bambu saindo como antenas—ele é o controlador—e eles esperam que os aviões a aterrar. Estão a fazer tudo bem. A forma é perfeita. Parece exactamente como era antes. Mas não funciona. Os aviões não aterram. Então eu chamo essas coisas de ciência do culto de carga, porque eles seguem todos os preceitos aparentes e formas de Investigação Científica, mas eles estão perdendo algo essencial, porque os aviões não aterram.
— Richard Feynman
I find it useful to draw a contrast between two different organizational development styles:” process-oriented “and” commitment-oriented ” development. O desenvolvimento orientado a processos alcança sua eficácia através de planejamento hábil, uso de processos cuidadosamente definidos, uso eficiente do tempo disponível e aplicação hábil das melhores práticas de engenharia de software. Este estilo de desenvolvimento tem sucesso porque a organização que o USA está constantemente melhorando. Mesmo que suas tentativas iniciais sejam ineficazes, atenção constante ao processo significa que cada tentativa sucessiva funcionará melhor do que a tentativa anterior.
Desenvolvimento Orientado para o compromisso passa por vários nomes, incluindo “desenvolvimento orientado para o herói” e “empoderamento individual”.”As organizações orientadas para o compromisso são caracterizadas pela contratação das melhores pessoas possíveis, pedindo-lhes total comprometimento com seus projetos, capacitando-as com autonomia quase completa, motivando-as a um grau extremo, e depois vendo que elas trabalham 60, 80 ou 100 horas por semana até que o projeto esteja concluído. O desenvolvimento orientado para o compromisso deriva sua potência de sua tremenda capacidade motivacional-estudo após estudo descobriu que a motivação individual é de longe o maior contribuinte único para a produtividade. Os desenvolvedores fazem compromissos voluntários e pessoais com os projetos em que trabalham, e muitas vezes se esforçam para fazer seus projetos serem bem sucedidos.Quando usado com conhecimento, qualquer estilo de desenvolvimento pode produzir software de alta qualidade econômica e rapidamente. Mas ambos os estilos de desenvolvimento têm lookalikes patológicos que não funcionam quase tão bem, e que pode ser difícil distinguir dos artigos genuínos.
a organização impostora do processo baseia as suas práticas numa devoção servil ao processo por causa do processo. Essas organizações olham para organizações orientadas a processos como o Laboratório de Engenharia de Software da NASA e a antiga divisão Federal de sistemas da IBM. Eles observam que essas organizações geram muitos documentos e realizam reuniões frequentes. Concluem que, se gerarem um número equivalente de documentos e realizarem um número comparável de reuniões, serão igualmente bem sucedidos. Se gerarem mais documentação e realizarem mais reuniões, serão ainda mais bem sucedidos! Mas eles não entendem que a documentação e as reuniões não são responsáveis pelo sucesso; são os efeitos secundários de alguns processos específicos eficazes. Nós chamamos essas organizações burocráticas porque elas colocam a forma de processos de software acima da substância. O seu mau uso do processo é desmotivante, o que prejudica a produtividade. E não são muito agradáveis de trabalhar.
a organização impostora do COMPROMISSO centra-se principalmente na motivação das pessoas para trabalhar longas horas. Estas organizações olham para empresas de sucesso como a Microsoft; observam que geram muito pouca documentação; oferecem opções de acções aos seus empregados; e depois exigir-lhes que trabalhem montes de horas extraordinárias. Eles concluem que se eles, também, minimizar a documentação, oferecer opções de ações, e exigir extensas horas extras, eles serão bem sucedidos. Quanto menos documentação e mais horas extras, melhor! Mas essas organizações sentem falta do fato de que a Microsoft e outras empresas bem sucedidas orientadas para o compromisso não exigem horas extras. Eles contratam pessoas que adoram criar software. Eles unem essas pessoas com outras pessoas que adoram criar software tanto quanto eles. Eles fornecem amplo apoio organizacional e recompensas para a criação de software. E depois soltam-nos. O resultado natural é que desenvolvedores de software e gerentes optam por trabalhar longas horas voluntariamente. Organizações impostoras confundem o efeito (longas horas) com a causa (motivação elevada). Chamamos as organizações impostoras de “sweatshops” porque elas enfatizam trabalhar duro ao invés de trabalhar inteligente, e elas tendem a ser caóticas e ineficazes. Também não são muito agradáveis de trabalhar.À primeira vista, estes dois tipos de organizações impostoras parecem ser opostos exatos. Um é incrivelmente burocrático, e o outro é incrivelmente caótico. Mas uma semelhança chave é realmente mais importante do que suas diferenças superficiais. Nenhum deles é muito eficaz, e a razão é que nenhum deles entende o que realmente faz os seus projectos serem bem sucedidos ou falharem. Eles passam pelos movimentos de olhar como organizações eficazes que são estilisticamente semelhantes. Mas sem qualquer entendimento real de por que as práticas funcionam, eles são essencialmente apenas espetando pedaços de bambu em suas orelhas e esperando que seus projetos aterrem com segurança. Muitos de seus projetos acabam caindo porque estes são apenas duas variedades diferentes de engenharia de software de culto de carga, semelhante em sua falta de compreensão do que faz projetos de software funcionar.A engenharia de software de culto de carga é fácil de identificar. Engenheiros de software de seita de carga justificam suas práticas dizendo:” Nós sempre fizemos isso assim no passado”, ou”nossos padrões da empresa exigem que o façamos desta maneira” —mesmo quando essas maneiras não fazem sentido. Eles se recusam a reconhecer os tradeoffs envolvidos em qualquer processo de desenvolvimento orientado ou de compromisso. Ambos têm pontos fortes e fracos. Quando confrontados com novas práticas mais eficazes, os engenheiros de software de culto de carga preferem ficar em suas cabanas de madeira de hábitos de trabalho familiares, confortáveis e-não necessariamente-eficazes. “Fazer a mesma coisa uma e outra vez e esperar resultados diferentes é um sinal de insanidade”, diz O velho ditado. Também é um sinal de engenharia de software de culto de carga.
o verdadeiro Debate
nesta revista e em muitas outras publicações, gastamos o nosso tempo a debater se o processo é bom ou individual empoderamento (por outras palavras, desenvolvimento orientado para o compromisso) pode ser melhor. Esta é uma falsa dicotomia. O processo é bom, assim como a capacitação individual. Os dois podem existir lado a lado. As organizações orientadas para o processo podem pedir um compromisso extremo em projetos específicos. As organizações orientadas para o compromisso podem usar práticas de engenharia de software habilmente.
a diferença entre estas duas abordagens realmente se resume a diferenças de estilo e personalidade. Eu trabalhei em vários projetos de cada estilo, e gostei de coisas diferentes sobre cada estilo. Alguns desenvolvedores gostam de trabalhar metodicamente em um horário de 8 a 5, o que é mais comum em empresas orientadas para o processo. Outros desenvolvedores gostam do foco e entusiasmo que vem com fazer um compromisso 24×7 para um projeto. Os projectos orientados para o compromisso são, em média, mais empolgantes, mas um projecto orientado para o processo pode ser igualmente empolgante quando tem uma missão bem definida e inspiradora. As organizações orientadas para o processo parecem degenerar em seus lookalikes patalógicos menos frequentemente do que as organizações orientadas para o compromisso fazem, mas qualquer estilo pode funcionar bem se for habilmente planejado e executado.
o facto de ambos os projectos orientados para o processo e orientados para o compromisso terem aspectos patológicos turvou o debate. Alguns projetos realizados em cada estilo têm sucesso, e outros fracassam. Isso permite a um advogado de processo apontar para o sucesso do processo e falhas de compromisso e afirmar que o processo é a chave para o sucesso. Permite que o defensor do COMPROMISSO faça a mesma coisa.
O problema que tem caído no esquecimento, enquanto nós fomos debatendo processo vs. compromisso é tão flagrante que, como a de Edgar Allen Poe furtado carta, ele pode simplesmente ter sido tão óbvio que temos esquecido. Não devíamos estar a debater o processo contra o compromisso; devíamos estar a debater a competência contra a incompetência. A verdadeira diferença não é qual estilo é escolhido, mas o que educação, formação e compreensão são trazidos para suportar sobre o projeto. Em vez de debater processo vs. compromisso, devemos procurar maneiras de aumentar o nível médio de competência de desenvolvedor e gerente. Isso irá melhorar as nossas hipóteses de sucesso, independentemente do estilo de desenvolvimento que escolhermos.
