Na semana passada, passei bastante tempo removendo o código morto de nossa base de códigos. Eu gosto de excluir o código. Quanto a mim, poucas coisas trazem o mesmo prazer que colocar as coisas em ordem no código. Sim, eu amo tanto que fico perplexo com os engenheiros que deixam código desnecessário no aplicativo. Mas, no fim de semana, ouvi alguém falando sobre o experimento de Milgram, "Submissão à autoridade" ( eles também escreveram sobre isso no hub) - e não pude deixar de traçar um paralelo entre a pessoa que chocou outro ser humano e o engenheiro que deixa erros conhecidos e código incorreto.
Se você não está familiarizado com o experimento de Stanley Milgram, consiste no fato de que o Experimentador (uma pessoa com autoridade) ordena que o Professor (o objeto de estudo) derrote o Aluno em uma série de descargas crescentes de corrente, que fica em outra sala. Ilustração da Wikipedia:
E - experimentador, T - professor, L - aprendiz
A essência do experimento foi estudar as reações das pessoas às ordens que conflitam com seus princípios morais. Antes do experimento, acreditava-se que a maioria dos sujeitos interromperia o experimento assim que percebessem que estavam prejudicando o aluno. No entanto, durante o experimento, verificou-se que um número impressionante de sujeitos atingiu uma descarga máxima de 450 volts.
No primeiro conjunto de experimentos de Milgram, 65% dos participantes (26 de 40 pessoas) usaram o valor máximo possível de 450 volts, embora não fosse agradável para eles fazer isso; em um determinado momento, cada participante parou e duvidou do experimento; alguns participantes queriam parar e devolver o dinheiro que pagaram pela participação. Durante o experimento, os participantes experimentaram vários graus de excitação e estresse. Eles suaram, tremeram, gaguejaram, morderam os lábios, gemeram, cravaram as unhas na pele, alguns riram nervosamente.
Quando aprendemos sobre esses resultados, queremos acreditar que nunca faríamos isso. Queremos acreditar que "apenas obedecer às ordens" é uma falha humana que não temos. Porém, experimentos como o de Milgram mostram que essa fé é otimista na melhor das hipóteses e completamente errada na pior.
E agora que sabemos como as pessoas reagem à autoridade, quando a dor física está em jogo, vamos ver como os programadores reagem à autoridade quando se trata de coisas mais abstratas, como frustração e inconveniência. Vamos pegar o diagrama do experimento de Milham e re-projetá-lo para refletir a equipe de desenvolvimento:
Se olharmos para a equipe de desenvolvimento, como mostrado na ilustração, não é de surpreender que os engenheiros deixem códigos ruins e deixem erros conhecidos. Provavelmente, em algum momento, a pessoa no poder deixou claro que não temos tempo para corrigir problemas ou que esses problemas não são priorizados em comparação com outras coisas no roteiro. Ou que a remoção de código morto não agrega valor ao usuário. Como resultado, deixamos o código como está e passamos à próxima tarefa, embora isso entre em conflito com nossa bússola moral e com os conceitos do que é bom e do que é ruim.
No experimento de Milgram, os sujeitos frequentemente hesitavam e protestavam contra o envio de outra descarga para uma pessoa em outra sala. Nesses casos, o pesquisador exigiu a continuação de uma das frases predefinidas:
- “Por favor, continue” (Por favor, continue / Continue);
- "A experiência exige que você continue";
- "É absolutamente essencial que você continue" (É absolutamente essencial que você continue);
- "Você não tem outra escolha, você deve continuar".
Usando apenas palavras, o pesquisador foi capaz de garantir que 65% dos indivíduos contra sua vontade espancassem outras pessoas com descargas de corrente muito dolorosas. Gostaria de saber que palavras usamos no contexto do desenvolvimento de software?
- Não é isso que decidimos, mas a equipe do produto
- Precisamos cumprir o prazo
- A equipe de marketing está prestes a lançar um comunicado de imprensa na próxima semana.
- Fechamos muito poucos ingressos
- De qualquer maneira, jogaremos esse código fora
- Esta é uma solução temporária.
- Precisa melhorar o desempenho da sua equipe
- Isso afetará um pequeno número de usuários.
- Isso não é uma prioridade para nós agora.
- Vamos consertar isso mais tarde
- É isso que a gerência quer
- Por que tanto tempo?
- Precisa fazer isso mais rápido.
Não estou escrevendo sobre isso para sugerir uma solução. Eu não tenho. Escrevo para cultivar - antes de tudo em mim - simpatia e compreensão . Quando vejo um código que deixa um sentimento de perplexidade ou comportamento que não entendo, devo lembrar que as ações nem sempre refletem intenções. Devo lembrar que os engenheiros deixam código incorreto não porque não se importam - eles deixam código incorreto porque não tiveram a liberdade de colocá-lo em ordem. E eles deixam erros não porque não se importam com os usuários, mas porque não tinham autoridade para se desviar do roteiro do produto.