Leis que não são leis

Nenhuma destas cinco “leis” foi provada em laboratório. São ditados, regras práticas que resumem numa frase algo que muita gente aprendeu errando. E é justamente por isso que funcionam: são fáceis de lembrar na hora em que mais importam.

Cada uma responde a uma pergunta diferente do dia a dia: o que pode dar errado, se o problema está claro, se é hora de decidir, onde investir o próprio tempo e quem responde pelo resultado. Juntas, formam um pequeno roteiro para enfrentar qualquer problema, de um projeto de software a uma reforma em casa.

Um cuidado antes de começar: a origem de algumas delas é bem documentada, como a de Murphy; a de outras é incerta e circula sobretudo na internet. Ao longo do texto, deixamos claro o que é fato histórico e o que é atribuição popular.

Lei de Murphy

“Anything that can go wrong, will go wrong.”

“Tudo o que pode dar errado, dará errado.”

Origem: um trenó-foguete no deserto

Entre 1948 e 1949, a Força Aérea dos Estados Unidos conduziu o projeto MX981, na base de Muroc, depois rebatizada de Edwards, na Califórnia. O objetivo era medir quanta desaceleração o corpo humano aguenta, usando um trenó movido a foguetes que corria sobre trilhos e freava bruscamente. O coronel e médico John Paul Stapp servia de cobaia. ^[15]

O capitão e engenheiro Edward A. Murphy Jr. propôs sensores para medir a força sobre o cinto de Stapp. Num dos testes, os sensores marcaram zero: tinham sido instalados ao contrário. Irritado, Murphy teria dito algo como “se existe um jeito errado de fazer, ele vai achar”, referindo-se ao técnico. A versão exata da frase é disputada até hoje, mas a lei ganhou fama quando Stapp, numa entrevista coletiva, explicou que ninguém tinha se ferido nos testes porque a equipe sempre levava em conta a “lei de Murphy”. ^{[15] [7]}

O que ela ensina

Ao contrário do que parece, a lei de Murphy não é pessimismo: é prevenção. Para Stapp, ela significava pensar em tudo o que pode falhar antes do teste e agir para evitar. Não é uma previsão de azar; é um lembrete de que, com tempo e repetições suficientes, até o erro improvável aparece.

A indústria transformou essa ideia em técnica. No Japão dos anos 1960, Shigeo Shingo criou o poka-yoke, “à prova de erros”: dispositivos que tornam o engano impossível ou evidente. ^[16] O pen drive que só entra de um lado e o carro que não dá a partida fora do “P” são exemplos do dia a dia.

Exemplos

• Um erro caro: em 1999, a sonda Mars Climate Orbiter, da NASA, se perdeu ao chegar a Marte porque uma equipe usava unidades métricas e a outra, unidades americanas. Ninguém conferiu a conversão. ^[14]
• Falhas de propósito: em 2011, a Netflix criou o Chaos Monkey, um programa que desliga servidores ao acaso em produção. Se a falha vai acontecer de qualquer jeito, melhor que aconteça quando a equipe está olhando. ^[10]
• Pré-mortem: o psicólogo Gary Klein propõe imaginar, antes de começar, que o projeto fracassou, e pedir a cada pessoa que escreva por quê. Os riscos aparecem antes de virar problemas. ^[6]
• No dia a dia: backup antes de formatar, pneu estepe calibrado, sair de casa com folga em dia de prova.

Lei de Kidlin

“If you can write it down, it is half solved.”

“Se você consegue escrever, está metade resolvido.”

Origem

Não se sabe quem foi Kidlin, e a lei circula sobretudo em textos de produtividade. ^[3] A ideia, porém, é antiga e tem pedigree: em 1938, o filósofo John Dewey escreveu que “é um ditado familiar e significativo que um problema bem formulado está metade resolvido”. ^[4]

O que ela ensina

Na cabeça, um problema é uma nuvem: mistura sintomas, suspeitas, emoções e urgência. Escrever obriga a escolher palavras, e escolher palavras obriga a pensar. Ao pôr no papel, você descobre o que sabe, o que não sabe e o que falta perguntar. O problema ganha contorno, e o que tem contorno pode ser medido, dividido e delegado.

Um roteiro simples ajuda: o quê acontece, quando, onde, desde quando, qual o impacto e como saberemos que foi resolvido.

Exemplos

• Relato de defeito: “o sistema está lento” não leva a lugar nenhum. “A tela de pedidos leva 12 segundos para abrir, só na região Sul, desde a versão 4.2” já aponta onde procurar.
• O pato de borracha: muitos programadores explicam o código, linha por linha, a um patinho de borracha, e descobrem o erro no meio da explicação. ^[17] Escrever tem o mesmo efeito.
• Histórias de usuário: “Como cliente, quero acompanhar meu pedido para saber quando ele chega” força o time a dizer quem, o quê e para quê.
• Na vida pessoal: listar as dívidas, com valor e juros de cada uma, costuma transformar a angústia em plano.

Lei de Falkland

“Until and unless absolutely necessary, don’t make that decision.”

“Até que seja absolutamente necessário, não tome essa decisão.”

Origem: o Parlamento inglês de 1641

A lei vem de Lucius Cary, segundo visconde de Falkland (c. 1610–1643), escritor e deputado inglês. Num debate de 1641 sobre abolir ou não os bispos da Igreja da Inglaterra, ele argumentou: “onde não é necessário mudar, é necessário não mudar”. Falkland morreu dois anos depois, na Primeira Batalha de Newbury, durante a Guerra Civil Inglesa. ^[13] Com o tempo, a frase foi adaptada para o mundo das decisões: “quando não é necessário tomar uma decisão, é necessário não tomar uma decisão”. ^[5]

O que ela ensina

Toda decisão fecha portas. Decidir cedo demais é decidir com pouca informação; decidir tarde demais é perder as opções. A lei de Falkland pede que se decida no momento certo: quando já se sabe o bastante e as alternativas ainda estão abertas. O desenvolvimento de software enxuto (lean) chama isso de último momento responsável: adiar compromissos irreversíveis até que adiar mais custe caro. ^[12]

Atenção: isso não é procrastinação. Esperar é uma escolha consciente, com data para decidir e com trabalho para reunir informação enquanto isso. E nem toda decisão merece espera. Jeff Bezos, fundador da Amazon, separa as decisões em dois tipos: portas de mão única, irreversíveis, que pedem calma e consulta; e portas de mão dupla, reversíveis, que devem ser tomadas rápido, porque errar custa pouco. ^[1]

Exemplos

• Arquitetura de software: não escolha hoje o banco de dados que só será necessário daqui a seis meses. Isole essa escolha atrás de uma interface e decida quando conhecer o volume real de dados.
• Contratação: contratar um especialista caro “por via das dúvidas” é uma porta de mão única. Um consultor por algumas semanas é uma porta de mão dupla.
• Reunião tensa: responder a um e-mail com raiva é uma decisão que raramente precisa ser tomada na hora. Dormir sobre o assunto custa pouco.
• Quando não esperar: um servidor fora do ar, um paciente na emergência, um prazo legal. Aí a decisão já é necessária.

Lei de Wilson

“If you have the right knowledge, the right money will flow to you.”

“Se você tiver o conhecimento certo, o dinheiro certo virá até você.”

Origem

Assim como a de Kidlin, a lei de Wilson não tem autor identificado. É apresentada como o princípio de que priorizar conhecimento e inteligência leva, com o tempo, ao sucesso, inclusive financeiro. ^[9] A ideia lembra a frase popularmente atribuída a Benjamin Franklin: “investir em conhecimento rende os melhores juros”.

O que ela ensina

O conhecimento funciona como juros compostos. Cada coisa que você aprende torna mais fácil aprender a próxima, e cada competência nova abre portas que geram novas oportunidades. O escritor James Clear popularizou uma conta que ilustra isso: melhorar 1% por dia durante um ano deixa você cerca de 37 vezes melhor; piorar 1% por dia leva quase a zero. ^[2]

1,01³⁶⁵ ≈ 37,8     → 1% melhor por dia, durante um ano
0,99³⁶⁵ ≈ 0,03     → 1% pior por dia, durante um ano

A conta é uma metáfora, não uma promessa: ninguém melhora exatamente 1% por dia. Mas ela mostra por que pequenos investimentos constantes vencem esforços grandes e raros. Repare também na palavra certo, que aparece duas vezes na lei: não é qualquer conhecimento, é o conhecimento que resolve problemas que alguém valoriza.

Exemplos

• Carreira em TI: quem aprendeu computação em nuvem ou análise de dados antes de virarem moda colheu as melhores oportunidades quando viraram.
• Profissional em T: profundidade numa área (a haste do T) somada a noções de várias outras (a barra) torna alguém difícil de substituir.
• Empresas: times que reservam tempo para estudo, documentação e troca de conhecimento resolvem problemas mais rápido e dependem menos de heróis.
• Hábito simples: 20 minutos de leitura por dia somam mais de 120 horas por ano.

Lei de Gilbert

“When you take on a task, finding the best ways to achieve the desired result is always your responsibility.”

“Quando você assume uma tarefa, encontrar as melhores maneiras de alcançar o resultado desejado é sempre responsabilidade sua.”

Origem

A lei costuma ser atribuída a Gilbert Lafayette Laws (1838–1907), político, editor de jornal e empresário americano, deputado pelo estado de Nebraska. ^{[8] [11]} Não há registro de que ele a tenha formulado, e um detalhe chama a atenção: o sobrenome dele era Laws, “leis” em inglês. É bem possível que “Gilbert’s Laws” tenha virado “lei de Gilbert” por pura confusão. Outra versão da mesma ideia diz que “o maior problema no trabalho é que ninguém diz o que fazer”. ^[8]

O que ela ensina

Seja qual for a origem, a mensagem é forte: se a tarefa é sua, o resultado também é. Falta de informação, um colega que não respondeu, uma ferramenta que não funciona: tudo isso são obstáculos a contornar, não desculpas para parar. Se ninguém diz o que fazer, pergunte. Se a informação não vem, vá buscá-la.

Isso não significa fazer tudo sozinho. Pedir ajuda, escalar um problema e avisar cedo que algo vai atrasar também são formas de assumir a responsabilidade. O contrário da lei de Gilbert não é pedir ajuda; é ficar esperando.

A lei vale também para quem lidera: se as pessoas não sabem o que se espera delas, parte do problema é de quem distribuiu as tarefas. Papéis claros e conversas abertas removem as barreiras que a lei manda cada um contornar. ^[8]

Exemplos

• Dependência atrasada: a API de outro time não ficou pronta. O dono da tarefa pergunta a data real, cria um dublê (mock) da API para seguir trabalhando e avisa o cliente sobre o risco.
• Requisito vago: em vez de entregar “o que dá para entender”, marque 15 minutos com quem pediu e confirme o que é sucesso.
• Definição de pronto: tarefa entregue não é código enviado; é o resultado funcionando para quem precisa dele.
• Em casa: quem se ofereceu para organizar a viagem da família cuida das reservas, mas também de confirmar horários com todos.

As cinco juntas

Isoladas, as leis são bons conselhos. Juntas, viram um roteiro: cinco perguntas para fazer diante de qualquer problema ou projeto, numa ordem que faz sentido.

Um caso prático: trocar o sistema de pedidos

Imagine uma loja que precisa trocar o sistema de pedidos antes da Black Friday. Veja como as cinco leis entram em cena:

• Kidlin: a equipe escreve o problema. “O sistema atual não aguenta mais de 500 pedidos por minuto; na última Black Friday tivemos 900 e o site caiu por 40 minutos. Meta: 1.500 pedidos por minuto até 1º de novembro.”
• Falkland: a escolha do novo fornecedor é uma porta de mão única e fica para depois de um teste de duas semanas. Já o layout da tela de pagamento é uma porta de mão dupla e é decidido na hora.
• Gilbert: cada entrega tem um dono com nome e sobrenome. Quando a integração com o meio de pagamento atrasa, a dona dessa entrega não espera: marca uma reunião com o fornecedor e combina um ambiente de testes provisório.
• Murphy: a equipe faz um pré-mortem e lista o que pode dar errado: pico maior que o previsto, falha no pagamento, dados migrados pela metade. Para cada risco, uma defesa: teste de carga, pagamento alternativo, migração ensaiada e um plano para voltar ao sistema antigo.
• Wilson: depois da Black Friday, a equipe registra o que aprendeu numa retrospectiva e numa página de documentação. O próximo projeto começa mais rápido.

Cuidados com cada lei

• Murphy não é pessimismo

  Prever falhas não é esperar o pior; é preparar-se para que o pior não aconteça.

• Kidlin não é burocracia

  Escrever o problema cabe em cinco linhas. O objetivo é clareza, não um relatório.

• Falkland não é procrastinação

  Adiar uma decisão exige data para decidir e trabalho para reunir informação.

• Wilson não é promessa de riqueza

  Conhecimento aumenta as chances, mas só rende quando resolve problemas de alguém.

• Gilbert não é fazer tudo sozinho

  Pedir ajuda e avisar cedo fazem parte da responsabilidade.

O processo

O roteiro também pode virar processo. No diagrama abaixo, em notação BPMN, cada lei ganha uma raia e o fluxo percorre o ciclo de vida de um sistema: da demanda escrita à decisão no momento certo, da entrega com dono às camadas de proteção, até o aprendizado que alimenta o próximo ciclo.

Repare que Murphy aparece duas vezes: no pré-mortem, antes de construir, e nas camadas de proteção, depois. E que nenhum caminho termina sem passar por Wilson: com ou sem falha, toda entrega deixa um registro do que se aprendeu.

Conclusão

Nenhuma das cinco leis tem a força de uma lei da física, e a autoria de algumas é, no mínimo, duvidosa. Mas elas sobreviveram porque condensam lições que custam caro para aprender na prática: as coisas falham, problemas confusos não se resolvem, decisões apressadas cobram juros, o conhecimento se acumula e o resultado precisa de um dono.

Da próxima vez que um problema aparecer, experimente as cinco perguntas: está escrito? Preciso decidir agora? Quem garante o resultado? O que pode dar errado? O que vou aprender com isso? Metade do trabalho, como diria Kidlin, já estará feita.

Revisão rápida

Referências

1. Bezos, J., “2015 Letter to Shareholders”, abril de 2016, sec.gov.
2. Clear, J., “Atomic Habits”, 2018, jamesclear.com.
3. Cosgun, H. H., “Solve any problem by Kidlin’s law”, Medium.
4. Dewey, J., “Logic: The Theory of Inquiry”, 1938, Wikiquote.
5. HulkApps, “Understanding Falkland’s Law: Embracing Patience in Decision-Making”, hulkapps.com.
6. Klein, G., “Performing a Project Premortem”, setembro de 2007, Harvard Business Review.
7. Toppr, “Murphy’s Law”, toppr.com.
8. Trojańczyk, A., “Gilbert’s Law: breaking down communication barriers for greater efficiency”, abril de 2024, trojanczyk.eu.
9. Trojańczyk, A., “Wilson’s Law: the key to success through intellectual growth”, março de 2024, trojanczyk.eu.
10. Wikipedia, “Chaos engineering”, en.wikipedia.org.
11. Wikipedia, “Gilbert L. Laws”, en.wikipedia.org.
12. Wikipedia, “Lean software development”, en.wikipedia.org.
13. Wikipedia, “Lucius Cary, 2nd Viscount Falkland”, en.wikipedia.org.
14. Wikipedia, “Mars Climate Orbiter”, en.wikipedia.org.
15. Wikipedia, “Murphy’s law”, en.wikipedia.org.
16. Wikipedia, “Poka-yoke”, en.wikipedia.org.
17. Wikipedia, “Rubber duck debugging”, en.wikipedia.org.

Laws that aren’t laws

None of these five “laws” was ever proven in a lab. They are sayings, rules of thumb that sum up in one sentence something many people learned the hard way. That is exactly why they work: they are easy to remember when they matter most.

Each one answers a different everyday question: what can go wrong, whether the problem is clear, whether it is time to decide, where to invest your time and who answers for the result. Together they make a small checklist for any problem, from a software project to a home renovation.

A word of caution before we start: the origin of some of them is well documented, as with Murphy’s; the origin of others is uncertain and circulates mostly online. Throughout the text, we make clear what is historical fact and what is popular attribution.

Murphy’s law

“Anything that can go wrong, will go wrong.”

Origin: a rocket sled in the desert

Between 1948 and 1949, the US Air Force ran project MX981 at Muroc, later renamed Edwards Air Force Base, in California. The goal was to measure how much deceleration the human body can take, using a rocket-powered sled that ran on rails and braked sharply. Colonel and flight surgeon John Paul Stapp rode it himself. ^[15]

Captain Edward A. Murphy Jr., an engineer, proposed sensors to measure the force on Stapp’s harness. In one test the sensors read zero: they had been wired backwards. Frustrated, Murphy reportedly said something like “if there is any way to do it wrong, he’ll find it”, referring to the technician. The exact wording is still disputed, but the law became famous when Stapp told a press conference that nobody had been hurt in the tests because the team always took “Murphy’s law” into account. ^{[15] [7]}

What it teaches

Contrary to appearances, Murphy’s law is not pessimism: it is prevention. For Stapp, it meant thinking about everything that could fail before the test and acting to prevent it. It is not a prediction of bad luck; it is a reminder that, given enough time and repetitions, even the unlikely error shows up.

Industry turned this idea into technique. In 1960s Japan, Shigeo Shingo created poka-yoke, “mistake-proofing”: devices that make an error impossible or obvious. ^[16] The plug that only fits one way and the car that won’t start outside “P” are everyday examples.

Examples

• A costly mistake: in 1999, NASA’s Mars Climate Orbiter was lost on arrival at Mars because one team used metric units and the other US customary units. Nobody checked the conversion. ^[14]
• Failing on purpose: in 2011, Netflix created Chaos Monkey, a program that randomly shuts down servers in production. If failure is going to happen anyway, better that it happens while the team is watching. ^[10]
• Pre-mortem: psychologist Gary Klein suggests imagining, before starting, that the project has failed, and asking everyone to write down why. Risks surface before they become problems. ^[6]
• Everyday life: a backup before formatting, an inflated spare tyre, leaving home early on exam day.

Kidlin’s law

“If you can write it down, it is half solved.”

Origin

Nobody knows who Kidlin was, and the law circulates mostly in productivity writing. ^[3] The idea, however, is old and has a pedigree: in 1938, philosopher John Dewey wrote that “it is a familiar and significant saying that a problem well-put is half-solved”. ^[4]

What it teaches

In your head, a problem is a cloud: it mixes symptoms, suspicions, emotions and urgency. Writing forces you to choose words, and choosing words forces you to think. Putting it on paper shows you what you know, what you don’t and what you still need to ask. The problem takes shape, and what has a shape can be measured, split and delegated.

A simple template helps: what happens, when, where, since when, what the impact is and how we will know it is solved.

Examples

• Bug report: “the system is slow” leads nowhere. “The orders screen takes 12 seconds to open, only in the southern region, since version 4.2” already points to where to look.
• The rubber duck: many programmers explain their code, line by line, to a rubber duck, and find the bug halfway through the explanation. ^[17] Writing has the same effect.
• User stories: “As a customer, I want to track my order so that I know when it arrives” forces the team to say who, what and why.
• Personal life: listing your debts, with the amount and interest rate of each, often turns anxiety into a plan.

Falkland’s law

“Until and unless absolutely necessary, don’t make that decision.”

Origin: the English Parliament of 1641

The law comes from Lucius Cary, 2nd Viscount Falkland (c. 1610–1643), an English writer and member of Parliament. In a 1641 debate on whether to abolish the bishops of the Church of England, he argued that “where it is not necessary to change, it is necessary not to change”. Falkland died two years later at the First Battle of Newbury, during the English Civil War. ^[13] Over time, the phrase was adapted to decision-making: “when it is not necessary to make a decision, it is necessary not to make a decision”. ^[5]

What it teaches

Every decision closes doors. Deciding too early means deciding with little information; deciding too late means losing your options. Falkland’s law asks you to decide at the right time: when you know enough and the alternatives are still open. Lean software development calls this the last responsible moment: delaying irreversible commitments until delaying further would be costly. ^[12]

Note: this is not procrastination. Waiting is a conscious choice, with a date to decide and work to gather information in the meantime. And not every decision deserves to wait. Amazon founder Jeff Bezos splits decisions into two types: one-way doors, irreversible, which call for care and consultation; and two-way doors, reversible, which should be made quickly because getting them wrong costs little. ^[1]

Examples

• Software architecture: don’t pick today the database you will only need six months from now. Hide that choice behind an interface and decide when you know the real data volume.
• Hiring: hiring an expensive specialist “just in case” is a one-way door. A consultant for a few weeks is a two-way door.
• A tense meeting: replying to an email in anger is a decision that rarely has to be made on the spot. Sleeping on it costs little.
• When not to wait: a server down, a patient in the emergency room, a legal deadline. There, the decision is already necessary.

Wilson’s law

“If you have the right knowledge, the right money will flow to you.”

Origin

Like Kidlin’s, Wilson’s law has no identified author. It is presented as the principle that prioritizing knowledge and intelligence eventually leads to success, including financial success. ^[9] The idea echoes the line popularly attributed to Benjamin Franklin: “an investment in knowledge pays the best interest”.

What it teaches

Knowledge works like compound interest. Everything you learn makes the next thing easier to learn, and every new skill opens doors that create new opportunities. Writer James Clear popularized a calculation that illustrates this: getting 1% better every day for a year makes you about 37 times better; getting 1% worse every day takes you almost to zero. ^[2]

1.01³⁶⁵ ≈ 37.8     → 1% better per day, for a year
0.99³⁶⁵ ≈ 0.03     → 1% worse per day, for a year

The calculation is a metaphor, not a promise: nobody improves exactly 1% a day. But it shows why small, steady investments beat large, rare efforts. Notice also the word right, which appears twice in the law: not just any knowledge, but knowledge that solves problems someone values.

Examples

• IT careers: those who learned cloud computing or data analysis before they were fashionable reaped the best opportunities when they became so.
• T-shaped professional: depth in one area (the stem of the T) plus a working knowledge of several others (the bar) makes someone hard to replace.
• Companies: teams that set aside time for study, documentation and knowledge sharing solve problems faster and depend less on heroes.
• A simple habit: 20 minutes of reading a day adds up to more than 120 hours a year.

Gilbert’s law

“When you take on a task, finding the best ways to achieve the desired result is always your responsibility.”

Origin

The law is usually attributed to Gilbert Lafayette Laws (1838–1907), an American politician, newspaper publisher and businessman who represented Nebraska in Congress. ^{[8] [11]} There is no record that he ever stated it, and one detail stands out: his surname was Laws. It is quite possible that “Gilbert Laws” became “Gilbert’s law” by pure confusion. Another version of the same idea says that “the biggest problem at work is that no one tells you what to do”. ^[8]

What it teaches

Whatever its origin, the message is strong: if the task is yours, so is the result. Missing information, a colleague who didn’t reply, a tool that doesn’t work: these are obstacles to work around, not excuses to stop. If nobody tells you what to do, ask. If the information doesn’t come, go and get it.

That doesn’t mean doing everything alone. Asking for help, escalating a problem and warning early that something will be late are also ways of taking responsibility. The opposite of Gilbert’s law is not asking for help; it is waiting.

The law also applies to leaders: if people don’t know what is expected of them, part of the problem lies with whoever handed out the tasks. Clear roles and open conversations remove the barriers the law asks each person to work around. ^[8]

Examples

• A late dependency: another team’s API isn’t ready. The task owner asks for the real date, builds a mock of the API to keep working and warns the client about the risk.
• A vague requirement: instead of delivering “whatever makes sense”, book 15 minutes with whoever asked and confirm what success looks like.
• Definition of done: a delivered task is not code pushed; it is the result working for whoever needs it.
• At home: whoever volunteered to organize the family trip handles the bookings, but also confirms times with everyone.

The five together

On their own, the laws are good advice. Together, they become a checklist: five questions to ask about any problem or project, in an order that makes sense.

A practical case: replacing the order system

Imagine a shop that must replace its order system before Black Friday. Here is how the five laws come into play:

• Kidlin: the team writes the problem down. “The current system can’t handle more than 500 orders per minute; last Black Friday we had 900 and the site was down for 40 minutes. Goal: 1,500 orders per minute by 1 November.”
• Falkland: choosing the new vendor is a one-way door and waits until after a two-week trial. The layout of the checkout screen is a two-way door and is decided on the spot.
• Gilbert: every deliverable has a named owner. When the payment integration is late, its owner doesn’t wait: she sets up a meeting with the provider and agrees on a temporary test environment.
• Murphy: the team runs a pre-mortem and lists what could go wrong: a bigger peak than expected, payment failure, half-migrated data. For each risk, a defence: load testing, a backup payment method, a rehearsed migration and a plan to roll back to the old system.
• Wilson: after Black Friday, the team records what it learned in a retrospective and a documentation page. The next project starts faster.

Watch-outs for each law

• Murphy is not pessimism

  Anticipating failure is not expecting the worst; it is preparing so the worst doesn’t happen.

• Kidlin is not bureaucracy

  Writing the problem down fits in five lines. The goal is clarity, not a report.

• Falkland is not procrastination

  Postponing a decision requires a date to decide and work to gather information.

• Wilson is not a promise of wealth

  Knowledge raises your odds, but only pays off when it solves someone’s problem.

• Gilbert is not doing it all alone

  Asking for help and warning early are part of responsibility.

The process

The checklist can also become a process. In the diagram below, in BPMN notation, each law gets a lane and the flow runs through a system’s life cycle: from the written request to the decision at the right time, from the owned deliverable to the layers of protection, and on to the learning that feeds the next cycle.

Notice that Murphy appears twice: in the pre-mortem, before building, and in the layers of protection, afterwards. And no path ends without going through Wilson: with or without failure, every delivery leaves a record of what was learned.

Conclusion

None of the five laws has the force of a law of physics, and the authorship of some is doubtful at best. But they have survived because they condense lessons that are expensive to learn in practice: things fail, fuzzy problems don’t get solved, hasty decisions charge interest, knowledge accumulates and results need an owner.

Next time a problem shows up, try the five questions: is it written down? Do I need to decide now? Who owns the result? What can go wrong? What will I learn from it? Half the work, as Kidlin would say, will already be done.

Quick review

References

1. Bezos, J., “2015 Letter to Shareholders”, April 2016, sec.gov.
2. Clear, J., “Atomic Habits”, 2018, jamesclear.com.
3. Cosgun, H. H., “Solve any problem by Kidlin’s law”, Medium.
4. Dewey, J., “Logic: The Theory of Inquiry”, 1938, Wikiquote.
5. HulkApps, “Understanding Falkland’s Law: Embracing Patience in Decision-Making”, hulkapps.com.
6. Klein, G., “Performing a Project Premortem”, September 2007, Harvard Business Review.
7. Toppr, “Murphy’s Law”, toppr.com.
8. Trojańczyk, A., “Gilbert’s Law: breaking down communication barriers for greater efficiency”, April 2024, trojanczyk.eu.
9. Trojańczyk, A., “Wilson’s Law: the key to success through intellectual growth”, March 2024, trojanczyk.eu.
10. Wikipedia, “Chaos engineering”, en.wikipedia.org.
11. Wikipedia, “Gilbert L. Laws”, en.wikipedia.org.
12. Wikipedia, “Lean software development”, en.wikipedia.org.
13. Wikipedia, “Lucius Cary, 2nd Viscount Falkland”, en.wikipedia.org.
14. Wikipedia, “Mars Climate Orbiter”, en.wikipedia.org.
15. Wikipedia, “Murphy’s law”, en.wikipedia.org.
16. Wikipedia, “Poka-yoke”, en.wikipedia.org.
17. Wikipedia, “Rubber duck debugging”, en.wikipedia.org.

Leggi che non sono leggi

Nessuna di queste cinque “leggi” è mai stata dimostrata in laboratorio. Sono detti, regole pratiche che riassumono in una frase qualcosa che molti hanno imparato sbagliando. Ed è proprio per questo che funzionano: sono facili da ricordare quando servono di più.

Ognuna risponde a una domanda diversa della vita di tutti i giorni: cosa può andare storto, se il problema è chiaro, se è il momento di decidere, dove investire il proprio tempo e chi risponde del risultato. Insieme formano una piccola lista di controllo per qualsiasi problema, da un progetto software alla ristrutturazione di casa.

Un’avvertenza prima di cominciare: l’origine di alcune è ben documentata, come quella di Murphy; quella di altre è incerta e circola soprattutto su internet. Nel testo distinguiamo chiaramente i fatti storici dalle attribuzioni popolari.

Legge di Murphy

“Anything that can go wrong, will go wrong.”

“Tutto ciò che può andare storto, andrà storto.”

Origine: una slitta a razzo nel deserto

Tra il 1948 e il 1949, l’aeronautica militare degli Stati Uniti condusse il progetto MX981 nella base di Muroc, poi ribattezzata Edwards, in California. Lo scopo era misurare quanta decelerazione può sopportare il corpo umano, usando una slitta spinta da razzi che correva su rotaie e frenava di colpo. Il colonnello e medico John Paul Stapp faceva da cavia. ^[15]

Il capitano e ingegnere Edward A. Murphy Jr. propose dei sensori per misurare la forza sull’imbracatura di Stapp. In una prova i sensori segnarono zero: erano stati montati al contrario. Irritato, Murphy avrebbe detto qualcosa come “se c’è un modo di sbagliare, lui lo troverà”, riferendosi al tecnico. La formulazione esatta è ancora discussa, ma la legge divenne famosa quando Stapp spiegò in una conferenza stampa che nessuno si era ferito nelle prove perché la squadra teneva sempre conto della “legge di Murphy”. ^{[15] [7]}

Cosa insegna

Contrariamente alle apparenze, la legge di Murphy non è pessimismo: è prevenzione. Per Stapp significava pensare a tutto ciò che poteva fallire prima della prova e agire per evitarlo. Non è una previsione di sfortuna; è un promemoria che, con abbastanza tempo e ripetizioni, anche l’errore improbabile si presenta.

L’industria ha trasformato questa idea in tecnica. Nel Giappone degli anni Sessanta, Shigeo Shingo creò il poka-yoke, “a prova di errore”: dispositivi che rendono lo sbaglio impossibile o evidente. ^[16] La spina che entra in un solo verso e l’auto che non parte fuori dalla “P” sono esempi quotidiani.

Esempi

• Un errore costoso: nel 1999 la sonda Mars Climate Orbiter della NASA andò perduta all’arrivo su Marte perché un team usava unità metriche e l’altro unità americane. Nessuno controllò la conversione. ^[14]
• Guasti di proposito: nel 2011 Netflix creò Chaos Monkey, un programma che spegne server a caso in produzione. Se il guasto arriverà comunque, meglio che arrivi mentre la squadra sta guardando. ^[10]
• Pre-mortem: lo psicologo Gary Klein propone di immaginare, prima di iniziare, che il progetto sia fallito, e di chiedere a ciascuno di scrivere perché. I rischi emergono prima di diventare problemi. ^[6]
• Nella vita di tutti i giorni: un backup prima di formattare, la ruota di scorta gonfia, uscire di casa in anticipo il giorno dell’esame.

Legge di Kidlin

“If you can write it down, it is half solved.”

“Se riesci a scriverlo, è risolto a metà.”

Origine

Non si sa chi fosse Kidlin, e la legge circola soprattutto in testi sulla produttività. ^[3] L’idea, però, è antica e ha un pedigree: nel 1938 il filosofo John Dewey scrisse che “è un detto familiare e significativo che un problema ben posto è risolto a metà”. ^[4]

Cosa insegna

Nella testa, un problema è una nuvola: mescola sintomi, sospetti, emozioni e urgenza. Scrivere obbliga a scegliere le parole, e scegliere le parole obbliga a pensare. Mettendolo su carta scopri cosa sai, cosa non sai e cosa devi ancora chiedere. Il problema prende forma, e ciò che ha una forma si può misurare, dividere e delegare.

Uno schema semplice aiuta: cosa succede, quando, dove, da quando, qual è l’impatto e come sapremo che è risolto.

Esempi

• Segnalazione di un difetto: “il sistema è lento” non porta da nessuna parte. “La schermata ordini impiega 12 secondi ad aprirsi, solo nella regione Sud, dalla versione 4.2” indica già dove cercare.
• La papera di gomma: molti programmatori spiegano il codice, riga per riga, a una paperella di gomma, e trovano l’errore a metà spiegazione. ^[17] Scrivere ha lo stesso effetto.
• User story: “Come cliente, voglio seguire il mio ordine per sapere quando arriva” obbliga il team a dire chi, cosa e perché.
• Nella vita personale: elencare i debiti, con importo e interessi di ciascuno, spesso trasforma l’ansia in un piano.

Legge di Falkland

“Until and unless absolutely necessary, don’t make that decision.”

“Finché non è assolutamente necessario, non prendere quella decisione.”

Origine: il Parlamento inglese del 1641

La legge viene da Lucius Cary, secondo visconte di Falkland (c. 1610–1643), scrittore e deputato inglese. In un dibattito del 1641 sull’abolizione dei vescovi della Chiesa d’Inghilterra, sostenne che “dove non è necessario cambiare, è necessario non cambiare”. Falkland morì due anni dopo nella prima battaglia di Newbury, durante la guerra civile inglese. ^[13] Col tempo la frase è stata adattata al mondo delle decisioni: “quando non è necessario prendere una decisione, è necessario non prenderla”. ^[5]

Cosa insegna

Ogni decisione chiude delle porte. Decidere troppo presto significa decidere con poche informazioni; decidere troppo tardi significa perdere le opzioni. La legge di Falkland chiede di decidere al momento giusto: quando si sa abbastanza e le alternative sono ancora aperte. Lo sviluppo software snello (lean) lo chiama ultimo momento responsabile: rimandare gli impegni irreversibili finché rimandare ancora non diventa costoso. ^[12]

Attenzione: questa non è procrastinazione. Aspettare è una scelta consapevole, con una data per decidere e del lavoro per raccogliere informazioni nel frattempo. E non ogni decisione merita di aspettare. Jeff Bezos, fondatore di Amazon, divide le decisioni in due tipi: porte a senso unico, irreversibili, che richiedono calma e consultazione; e porte a doppio senso, reversibili, da prendere in fretta perché sbagliare costa poco. ^[1]

Esempi

• Architettura software: non scegliere oggi il database che servirà solo tra sei mesi. Isola questa scelta dietro un’interfaccia e decidi quando conoscerai il volume reale dei dati.
• Assunzioni: assumere uno specialista costoso “per sicurezza” è una porta a senso unico. Un consulente per qualche settimana è una porta a doppio senso.
• Una riunione tesa: rispondere a un’e-mail con rabbia è una decisione che raramente va presa sul momento. Dormirci sopra costa poco.
• Quando non aspettare: un server fuori servizio, un paziente al pronto soccorso, una scadenza legale. Lì la decisione è già necessaria.

Legge di Wilson

“If you have the right knowledge, the right money will flow to you.”

“Se hai la conoscenza giusta, i soldi giusti arriveranno da te.”

Origine

Come quella di Kidlin, la legge di Wilson non ha un autore identificato. Viene presentata come il principio secondo cui dare priorità alla conoscenza e all’intelligenza porta, col tempo, al successo, anche economico. ^[9] L’idea ricorda la frase popolarmente attribuita a Benjamin Franklin: “investire nella conoscenza rende i migliori interessi”.

Cosa insegna

La conoscenza funziona come l’interesse composto. Ogni cosa che impari rende più facile imparare la successiva, e ogni nuova competenza apre porte che creano nuove opportunità. Lo scrittore James Clear ha reso popolare un calcolo che lo illustra: migliorare dell’1% al giorno per un anno ti rende circa 37 volte migliore; peggiorare dell’1% al giorno ti porta quasi a zero. ^[2]

1,01³⁶⁵ ≈ 37,8     → 1% meglio al giorno, per un anno
0,99³⁶⁵ ≈ 0,03     → 1% peggio al giorno, per un anno

Il calcolo è una metafora, non una promessa: nessuno migliora esattamente dell’1% al giorno. Ma mostra perché piccoli investimenti costanti battono grandi sforzi rari. Nota anche la parola giusto, che compare due volte nella legge: non una conoscenza qualsiasi, ma quella che risolve problemi a cui qualcuno dà valore.

Esempi

• Carriera nell’IT: chi ha imparato il cloud computing o l’analisi dei dati prima che diventassero di moda ha raccolto le migliori opportunità quando lo sono diventati.
• Professionista a T: profondità in un’area (l’asta della T) più nozioni di molte altre (la barra) rendono una persona difficile da sostituire.
• Aziende: i team che riservano tempo allo studio, alla documentazione e allo scambio di conoscenze risolvono i problemi più in fretta e dipendono meno dagli eroi.
• Un’abitudine semplice: 20 minuti di lettura al giorno fanno più di 120 ore all’anno.

Legge di Gilbert

“When you take on a task, finding the best ways to achieve the desired result is always your responsibility.”

“Quando ti assumi un compito, trovare i modi migliori per raggiungere il risultato desiderato è sempre una tua responsabilità.”

Origine

La legge viene di solito attribuita a Gilbert Lafayette Laws (1838–1907), politico, editore di giornali e imprenditore americano, deputato per il Nebraska. ^{[8] [11]} Non c’è traccia che l’abbia mai formulata, e un dettaglio salta all’occhio: il suo cognome era Laws, “leggi” in inglese. È molto probabile che “Gilbert Laws” sia diventato “legge di Gilbert” per pura confusione. Un’altra versione della stessa idea dice che “il problema più grande al lavoro è che nessuno ti dice cosa fare”. ^[8]

Cosa insegna

Qualunque sia l’origine, il messaggio è forte: se il compito è tuo, anche il risultato lo è. Informazioni mancanti, un collega che non ha risposto, uno strumento che non funziona: sono ostacoli da aggirare, non scuse per fermarsi. Se nessuno ti dice cosa fare, chiedi. Se l’informazione non arriva, vai a prenderla.

Questo non significa fare tutto da soli. Chiedere aiuto, segnalare un problema a chi può risolverlo e avvisare per tempo che qualcosa sarà in ritardo sono anch’essi modi di assumersi la responsabilità. Il contrario della legge di Gilbert non è chiedere aiuto; è restare ad aspettare.

La legge vale anche per chi guida: se le persone non sanno cosa ci si aspetta da loro, parte del problema è di chi ha distribuito i compiti. Ruoli chiari e conversazioni aperte eliminano le barriere che la legge chiede a ciascuno di aggirare. ^[8]

Esempi

• Una dipendenza in ritardo: l’API di un altro team non è pronta. Il responsabile del compito chiede la data reale, crea un finto (mock) dell’API per continuare a lavorare e avvisa il cliente del rischio.
• Un requisito vago: invece di consegnare “quello che si capisce”, fissa 15 minuti con chi l’ha chiesto e conferma cosa significa successo.
• Definizione di fatto: un compito consegnato non è codice inviato; è il risultato che funziona per chi ne ha bisogno.
• A casa: chi si è offerto di organizzare il viaggio di famiglia si occupa delle prenotazioni, ma anche di confermare gli orari con tutti.

Le cinque insieme

Da sole, le leggi sono buoni consigli. Insieme diventano una lista di controllo: cinque domande da porsi davanti a qualsiasi problema o progetto, in un ordine che ha senso.

Un caso pratico: sostituire il sistema degli ordini

Immagina un negozio che deve sostituire il sistema degli ordini prima del Black Friday. Ecco come entrano in gioco le cinque leggi:

• Kidlin: il team scrive il problema. “Il sistema attuale non regge più di 500 ordini al minuto; lo scorso Black Friday ne abbiamo avuti 900 e il sito è rimasto giù per 40 minuti. Obiettivo: 1.500 ordini al minuto entro il 1° novembre.”
• Falkland: la scelta del nuovo fornitore è una porta a senso unico e aspetta la fine di una prova di due settimane. Il layout della schermata di pagamento, invece, è una porta a doppio senso e si decide subito.
• Gilbert: ogni consegna ha un responsabile con nome e cognome. Quando l’integrazione con il sistema di pagamento è in ritardo, la sua responsabile non aspetta: fissa una riunione con il fornitore e concorda un ambiente di test provvisorio.
• Murphy: il team fa un pre-mortem ed elenca cosa può andare storto: un picco maggiore del previsto, un guasto nei pagamenti, dati migrati a metà. Per ogni rischio, una difesa: test di carico, un metodo di pagamento alternativo, una migrazione provata e un piano per tornare al vecchio sistema.
• Wilson: dopo il Black Friday, il team registra ciò che ha imparato in una retrospettiva e in una pagina di documentazione. Il progetto successivo parte più in fretta.

Attenzione a ogni legge

• Murphy non è pessimismo

  Prevedere i guasti non è aspettarsi il peggio; è prepararsi perché il peggio non accada.

• Kidlin non è burocrazia

  Scrivere il problema sta in cinque righe. Lo scopo è la chiarezza, non un rapporto.

• Falkland non è procrastinazione

  Rimandare una decisione richiede una data per decidere e lavoro per raccogliere informazioni.

• Wilson non promette ricchezza

  La conoscenza aumenta le probabilità, ma rende solo quando risolve il problema di qualcuno.

• Gilbert non è fare tutto da soli

  Chiedere aiuto e avvisare per tempo fanno parte della responsabilità.

Il processo

La lista di domande può diventare anche un processo. Nel diagramma qui sotto, in notazione BPMN, ogni legge ha una corsia e il flusso attraversa il ciclo di vita di un sistema: dalla richiesta scritta alla decisione al momento giusto, dalla consegna con un responsabile ai livelli di protezione, fino all’apprendimento che alimenta il ciclo successivo.

Nota che Murphy compare due volte: nel pre-mortem, prima di costruire, e nei livelli di protezione, dopo. E nessun percorso finisce senza passare da Wilson: con o senza guasti, ogni consegna lascia traccia di ciò che si è imparato.

Conclusione

Nessuna delle cinque leggi ha la forza di una legge della fisica, e la paternità di alcune è quantomeno dubbia. Ma sono sopravvissute perché condensano lezioni che costa caro imparare sul campo: le cose si guastano, i problemi confusi non si risolvono, le decisioni affrettate si pagano con gli interessi, la conoscenza si accumula e il risultato ha bisogno di un responsabile.

La prossima volta che si presenta un problema, prova le cinque domande: è scritto? Devo decidere adesso? Chi garantisce il risultato? Cosa può andare storto? Cosa imparerò? Metà del lavoro, come direbbe Kidlin, sarà già fatta.

Ripasso veloce

Riferimenti

1. Bezos, J., “2015 Letter to Shareholders”, aprile 2016, sec.gov.
2. Clear, J., “Atomic Habits”, 2018, jamesclear.com.
3. Cosgun, H. H., “Solve any problem by Kidlin’s law”, Medium.
4. Dewey, J., “Logic: The Theory of Inquiry”, 1938, Wikiquote.
5. HulkApps, “Understanding Falkland’s Law: Embracing Patience in Decision-Making”, hulkapps.com.
6. Klein, G., “Performing a Project Premortem”, settembre 2007, Harvard Business Review.
7. Toppr, “Murphy’s Law”, toppr.com.
8. Trojańczyk, A., “Gilbert’s Law: breaking down communication barriers for greater efficiency”, aprile 2024, trojanczyk.eu.
9. Trojańczyk, A., “Wilson’s Law: the key to success through intellectual growth”, marzo 2024, trojanczyk.eu.
10. Wikipedia, “Chaos engineering”, en.wikipedia.org.
11. Wikipedia, “Gilbert L. Laws”, en.wikipedia.org.
12. Wikipedia, “Lean software development”, en.wikipedia.org.
13. Wikipedia, “Lucius Cary, 2nd Viscount Falkland”, en.wikipedia.org.
14. Wikipedia, “Mars Climate Orbiter”, en.wikipedia.org.
15. Wikipedia, “Murphy’s law”, en.wikipedia.org.
16. Wikipedia, “Poka-yoke”, en.wikipedia.org.
17. Wikipedia, “Rubber duck debugging”, en.wikipedia.org.