50 Laws, Principles, and Mental Models That Improve Decisions, Projects, and Troubleshooting

These are not laws in the scientific sense. They are compact heuristics: useful patterns for planning work, diagnosing systems, managing incentives, and avoiding predictable errors in judgment. None should replace evidence, measurements, or domain knowledge. Used together, however, they provide a practical vocabulary for thinking more clearly.

Time, work, and project execution

1. Parkinson’s Law

Work expands to fill the time available for its completion.

Give a task a week and it tends to become a week-long task; give it two hours and people often find a two-hour version. Use time boxes and clear completion criteria, while allowing sufficient time for safety-critical work and verification.

2. Hofstadter’s Law

It always takes longer than expected, even when you account for it taking longer.

Estimates miss integration problems, unknown dependencies, rework, coordination, testing, and learning curves. Build contingency into schedules and treat early estimates as ranges rather than promises.

3. Brooks’s Law

Adding people to a late software project makes it later.

New people require onboarding, communication paths multiply, and work may not be divisible. The broader lesson applies to any complex effort: add capacity early, modularize work, and do not confuse headcount with immediate throughput.

4. Law of Triviality

Groups often spend disproportionate time on small, familiar issues while neglecting consequential, complicated ones.

People can debate a low-cost visible detail because everyone understands it, while avoiding the expensive technical decision that actually matters. Time-box discussion and scale meeting time to the decision’s impact.

5. Law of Diminishing Returns

After a point, each additional unit of effort produces less additional benefit.

The first hour spent fixing an obvious defect can be highly valuable; the tenth hour spent polishing an already adequate result may add little. Compare marginal benefit with marginal cost before continuing.

Judgment, explanation, and diagnosis

6. Hanlon’s Razor

Do not attribute to malice what can be adequately explained by error, ignorance, carelessness, or poor incentives.

Start by checking facts, process, competence, incentives, and communication. This is not a rule to ignore deliberate misconduct; it is a warning against assuming intent without evidence.

7. Occam’s Razor

When competing explanations fit the evidence equally well, prefer the one requiring fewer unsupported assumptions.

Start diagnostics with common, testable failure modes: power, ground, fuses, connections, configuration, wear items, and known failure patterns. “Simple” does not mean “convenient,” and a simple explanation must still fit the evidence.

8. Murphy’s Law

If a failure mode is possible in a real system, assume it will eventually occur under the wrong conditions.

Design for foreseeable mistakes, vibration, contamination, reversed connections, weak batteries, bad weather, overload, and maintenance errors. Add protection, inspection access, fault indication, and safe failure modes.

9. First-Principles Thinking

Break a problem down to constraints and observable facts instead of copying conventional answers.

For a mechanical or electrical project, start with loads, forces, voltage drop, heat, materials, clearances, required reliability, and safety margin. Conventional practice can be useful, but should not substitute for understanding.

10. Five Whys

Repeatedly ask why a failure occurred to move from a symptom toward contributing causes.

Use it as a structured investigation, not a way to invent a story. Stop when the next answer needs evidence you do not have, then gather measurements, records, inspections, or controlled tests.

11. Falsifiability

A useful claim specifies what evidence could show it to be wrong.

Replace “the module is bad” with a testable statement: supply voltage, ground voltage drop, communication state, command signal, output under load, and the expected result. Diagnostic claims should be capable of failing a test.

12. Bayesian Updating

Adjust confidence in an explanation as new evidence arrives.

Begin with base rates and common faults, then update sharply when a measurement discriminates between explanations. A verified low supply voltage should shift attention away from a suspected controller fault until the supply issue is resolved.

13. Burden of Proof

About The Author