Useful Laws & Principles

Anything that can go wrong eventually will, so plan for failure.

Murphy's Law doesn't literally mean “bad things will definitely happen.” It's more useful as a reminder: if a failure is possible, eventually you'll encounter it, so don't build a system that depends on everything going perfectly.

You spend weeks preparing for a product demo. Everything works perfectly in testing. Five minutes before the client joins, the demo environment goes down. You had assumed it was too unlikely to prepare for, so now the entire demo is at risk.

You leave home 10 minutes early because you have an important meeting. You normally arrive in 20 minutes. That particular day, you encounter a traffic jam, your phone battery dies, and the elevator stops at every floor.

Work expands to fill the time available.

The key idea: More time doesn't necessarily mean more productivity. It often creates room for unnecessary work.

Your manager asks for a report by Friday. You start Monday, spend days tweaking the formatting, rewriting sentences, checking tiny details, and thinking of things to add. By Friday, it's finally done. The next time, you're asked for the same report by tomorrow—and you manage to produce a perfectly acceptable version in a few hours.

A more memorable everyday version: You have a flight at 8 PM, so you plan to leave home at 6 PM. Somehow, you're still getting ready at 5:50 PM. Give yourself only 30 minutes, and suddenly you can get ready surprisingly quickly.

Things take longer than expected—even when you account for that.

Easy way to remember it: “It's going to take longer than you think—even after you've allowed for it taking longer.”

You plan to renovate your kitchen in 3 weeks, so you add a 1-week buffer and tell yourself it will take 4 weeks. Then you discover old plumbing needs replacing, a cabinet doesn't fit, the countertop is delayed, and the electrician finds another issue. Even though you deliberately allowed extra time, the renovation takes 7 weeks.

A small number of causes often produce most of the results.

The key idea: Don't treat everything as equally important. Find the small number of things producing the biggest impact.

Importantly, 80/20 isn't a mathematical rule that must literally be 80% and 20%. It means the distribution is often highly uneven—for example, 10% of causes might produce 70% of the results, or 30% might produce 90%.

A software company analyzes 10,000 customer support tickets and discovers that just 20% of the recurring issues account for 80% of all complaints. Instead of trying to fix everything at once, the team focuses on those few issues and eliminates most of the customer frustration.

Another very relatable example: You have 100 apps on your phone, but you probably spend most of your time using just 10–20 of them. A small number of apps generate most of your usage.

The more choices people have, the longer and harder it becomes to make a decision.

The key UX idea: Don't give users every possible choice at once. Reduce, group, prioritize, or progressively reveal choices.

One important nuance: Hick's Law doesn't mean “fewer choices are always better.” If users genuinely need many choices, good categorization, search, filtering, and progressive disclosure can reduce the decision burden.

You're designing a checkout page. If you show users 3 clearly labeled payment options—UPI, Card, Net Banking—they can choose quickly. If you show 15 payment methods with equal visual emphasis, users have to scan and compare them, slowing down the decision.

A more everyday example: Imagine buying ice cream. The shop has 5 flavors → you pick one almost immediately. It has 50 flavors → you start comparing, second-guessing yourself, and may even leave without deciding.

When several explanations fit the facts, start with the simplest one that explains the evidence.

The key idea: Don't jump to a complicated explanation when a simple explanation fits the evidence.

The important caveat: Occam's Razor doesn't say the simplest explanation is always correct. It says it's generally sensible to investigate the simpler explanation first when multiple explanations are consistent with what you know.

Your website suddenly becomes very slow. You could suspect a database failure, a server problem, or a major security issue. Before investigating all of those, you check the latest deployment—and discover someone accidentally uploaded a 10 MB image to the homepage.

A more memorable everyday example: You walk into your house and find the lights aren't working. Possible explanations include a wiring failure, a damaged electrical panel, or a city-wide power problem. Before calling an electrician, you look outside and realize the entire neighborhood has lost power.

Don't assume bad intentions when a mistake, oversight, or incompetence can explain what happened.

The key idea: Don't assign malicious intent when an ordinary mistake or misunderstanding explains the behavior.

Importantly, Hanlon's Razor doesn't mean “never assume bad intentions.” If there is evidence of deliberate behavior, you should consider it. The principle is about not jumping to that conclusion without evidence.

You arrive at a meeting and discover that a colleague didn't include you in an important presentation. Your first thought is that they deliberately left you out. Later, you discover they were working from an old version of the attendee list and simply missed your name.

A more memorable everyday example: Someone cuts in front of you in traffic. You immediately think, “What an arrogant person.” Then you notice they're trying to get into a hospital emergency entrance.

Don't remove or change something until you understand why it exists.

The key idea: If you don't understand why something exists, you don't yet know whether it's safe to remove it.

This is particularly useful when redesigning existing products or processes. Before asking “How can we remove this?” ask “Why was this introduced in the first place?”

You are walking through a village and see a fence built across an otherwise open field. It looks pointless, so you remove it. Later, you discover the fence was there to stop livestock from wandering onto the road. What looked unnecessary actually had a purpose.

A great UX/product version: You redesign a form and remove a seemingly unnecessary confirmation step because it adds friction. Later, you discover that the confirmation was deliberately added because users were frequently submitting expensive orders by mistake.

When a measurement becomes a target, people may optimize the measurement instead of the real goal.

The key idea: When the metric becomes the goal, people learn to game the metric.

That's the heart of Goodhart's Law: what you measure ≠ necessarily what you actually care about.

A customer-support team wants to improve customer service, so management sets a target of resolving each ticket within 5 minutes. Initially, resolution time is just a useful measurement. But once agents are judged on it, they start rushing customers, closing tickets quickly, or avoiding complicated cases. The average resolution time improves—but customer service gets worse.

A very simple example: A school wants students to learn more, so it measures success through test scores. Once test scores become the main target, teachers may start teaching students how to pass the test rather than helping them understand the subject.

A well-intentioned incentive can create unintended behavior that makes the original problem worse.

The key idea: When you create an incentive, people will optimize for the reward—not necessarily for the outcome you intended.

Cobra Effect = Good intention + wrong incentive → unexpected behavior → worse outcome.

During British rule in India, the government wanted to reduce the number of cobras in Delhi, so it offered people a reward for every dead cobra they brought in. At first, people killed cobras to collect the reward. But some realized they could breed cobras and then kill them for the reward. When the government discovered this and cancelled the program, the breeders released the cobras they had been keeping. The policy intended to reduce the cobra population but may have ultimately increased the number of cobras.

A simple modern example: A company wants employees to work more, so it gives a bonus for every feature shipped. Developers start splitting large features into many tiny features just to increase their bonus.

Clearly defining and writing down a problem can reveal much of the solution.

The key idea: A vague problem leads to vague solutions. A clearly written problem gives you something specific to solve.

One caveat: Kidlin's Law isn't a formal scientific law like a law of physics. It's a popular problem-solving principle, and its exact attribution and wording are uncertain. The underlying idea—problem definition is a critical part of problem solving—is much more established.

A product team says, “Users don't like our app.” Instead of immediately redesigning it, they write down what is actually happening: “40% of new users abandon the signup process because they don't understand why we need their phone number.” The problem is now specific—and the team can investigate whether explaining the reason or changing the requirement improves signup.

A simple everyday example: “I'm always late for work.” Write it down properly: “I leave home at 9:05, but my commute takes 45 minutes and I need to arrive by 9:30.” Suddenly, the problem isn't “I'm bad at being punctual.” It's “I need to leave by 8:45.”

People tend to be promoted based on success in their current role until they reach a role that requires skills they haven't demonstrated.

The key idea: Being good at your current job doesn't necessarily mean you'll be good at the job you're promoted into.

One important nuance: The Peter Principle doesn't mean “people become incompetent after every promotion.” It's a tendency or hypothesis about how promotion based primarily on current-role performance can place people into roles requiring different competencies.

A great salesperson consistently exceeds targets, so the company promotes them to sales manager. But the new job is less about selling and more about coaching people, hiring, planning territories, and managing performance. Being an excellent salesperson doesn't automatically make them an excellent manager.

A particularly good tech example: A developer becomes a tech lead because they're the strongest coder on the team. As tech lead, however, they spend less time coding and more time making architectural decisions, communicating with stakeholders, mentoring developers, and resolving conflicts. Their success now depends on a different set of skills.

Adding people to a late software project can make it even later.

The key idea: Adding people doesn't instantly add productivity—especially when the project is already late.

An important nuance: Brooks's Law doesn't mean “never add people to a project.” It applies particularly when the project is already late, the work requires significant coordination, and new people need substantial onboarding.

A team of 5 developers is building a product that is already two months behind schedule. Management adds 5 more developers hoping to catch up. But the original developers now have to explain the architecture, review the new developers' work, answer questions, and coordinate across a much larger team. For a while, the team spends more time communicating than building, pushing the deadline even further away.

A memorable analogy: Imagine 5 people cooking dinner in a small kitchen. Adding 5 more people doesn't necessarily make dinner twice as fast. Now everyone is bumping into each other, asking what to do, and getting in each other's way.

People with limited knowledge can sometimes overestimate their ability because they don't yet recognize what they don't know.

The key idea: The less you know about a subject, the harder it can be to recognize the limits of your own knowledge.

One important nuance: The Dunning-Kruger effect is not simply “stupid people think they're smart.” The underlying research concerns how accurately people assess their own performance, particularly when limited knowledge also limits their ability to recognize mistakes and gaps in understanding.

Someone watches a few videos about investing, makes a couple of profitable trades, and concludes they've figured out the stock market. They start taking much larger risks. Only after experiencing different market conditions do they discover how much they didn't understand about risk, valuation, diversification, and market behavior.

A simple everyday example: Someone learns the rules of chess in an afternoon and thinks, “I know how to play chess.” Then they play an experienced player and realize that knowing the rules and understanding the game are very different things.

We continue investing in something because of what we've already spent, even when future investment may not be worthwhile.

The key idea: Money, time, or effort you've already spent is gone. The decision should be based on what happens from this point forward.

That's the essence of the sunk cost fallacy: letting the past influence a decision that should be based on the future.

You buy an expensive movie ticket, but 20 minutes into the movie you realize you're not enjoying it at all. You stay until the end because you think, “I've already paid for the ticket.” But the money is already gone—you could instead spend the next two hours doing something you actually enjoy.

A great business example: A company spends ₹50 lakh developing a product. After launch, customers show almost no interest. Management says, “We can't abandon it now—we've already spent ₹50 lakh.” The better question is: “If we hadn't spent that ₹50 lakh already, would we invest ₹10 lakh more today?”

We focus on the things that survived or succeeded while overlooking the ones that failed or disappeared.

The key idea: Don't just study the winners you can see. Ask: “Who or what is missing from the data?”

Survivorship bias is especially important when looking at success stories, case studies, investment returns, careers, and product success.

During WWII, engineers studied returning bombers and noticed bullet holes concentrated on the wings and fuselage. They initially considered adding armor there. Statistician Abraham Wald pointed out the missing information: these were the planes that survived and returned. The planes hit in critical areas—such as the engines—often never came back. So the armor needed to go where the returning planes had no bullet holes.

A modern example: You read stories about successful entrepreneurs who say, “I took a huge risk and succeeded.” You don't see the thousands of people who took similar risks, failed, and therefore don't have a success story to tell.

The architecture of a product tends to reflect the way the organization and its teams communicate.

The key idea: Your organization structure can become your software architecture.

An e-commerce company has separate teams for Catalog, Cart, Payments, and Delivery. Each team works independently and rarely coordinates with the others. Over time, the product develops four separate systems with complicated handoffs—the software ends up mirroring the way the teams are organized.

A memorable way to think about it: If four teams don't talk to each other, don't be surprised when the four parts of the product don't talk to each other either.

The more important a metric becomes for making decisions, the more likely people are to manipulate or distort the metric itself.

The key idea: When a measurement becomes high-stakes, people change their behavior—and eventually the measurement itself can become unreliable.

Goodhart vs. Campbell: Goodhart's Law is about people optimizing the target instead of the real goal: “Hit 100 calls → make lots of calls.” Campbell's Law is about high-stakes use corrupting the measurement itself: “Waiting time determines performance → manipulate how waiting time is recorded.”

A useful shortcut: Goodhart → game the target. Campbell → corrupt the measurement.

A hospital uses patient waiting time as a major measure of staff performance. Staff are rewarded for keeping the average below 10 minutes. Over time, some hospitals may start changing when the waiting-time clock starts or ends, moving patients between queues, or recording them differently to improve the reported number—even though patients aren't necessarily being served faster.

When something produces an unusually extreme result, the next result is often closer to its normal level.

The key idea: After an unusually good or bad result, the next result often moves closer to the person's or system's normal performance.

One important warning: Regression to the mean doesn't mean extreme results automatically cause the next result to be average. It's a statistical effect that occurs when results contain some combination of underlying ability + random variation.

A student normally scores around 70% on tests but gets 95% on one unusually easy test. On the next test, they score 72%. It doesn't necessarily mean they suddenly became worse—the 95% was an unusually high result, partly influenced by circumstances that didn't repeat.

A classic everyday example: A golfer normally shoots around 90. One day they shoot 75—an unusually brilliant round. The next week they shoot 88. You might think, “They suddenly got worse.” But they may simply have returned to their normal performance.

Be careful about conclusions like: “The treatment worked because the patient was extremely sick and then got better.” If the patient's condition naturally fluctuates, some improvement may have happened simply because an unusually bad measurement was likely to be followed by something closer to normal.

Software tends to become slower and more resource-hungry faster than hardware becomes faster.

The key idea: Hardware gets faster, but software gets heavier to take advantage of it.

Easy way to remember it: “Computers get faster. Software gets fatter.”

Your new laptop is several times more powerful than the computer you used 10 years ago. Yet a simple task like opening a text editor or loading a webpage can still feel surprisingly slow. Modern software has gained features, frameworks, background processes, animations, and larger resource requirements—so much of the hardware improvement gets consumed by increasingly complex software.

A very relatable example: Microsoft Word in the past could open a document almost instantly and did relatively little in the background. Modern productivity apps may constantly sync files, check spelling, load extensions, connect to cloud services, track collaboration, render complex interfaces, and run background processes. So despite having a computer that's dramatically more powerful, the simple experience isn't necessarily dramatically faster.