A handbook of useful principles, rules, laws and concepts that help understand patterns, make decisions and effectively solve practical problems. This collection brings together well-known and practically applicable ideas from development, testing, management, productivity and other fields.
Cognitive Biases and Thinking Principles
| Name | Alternative Name | Rule / Principle | Description |
|---|---|---|---|
| Pareto Principle | 80/20 Rule, Law of the Vital Few | 20% of efforts or causes yield 80% of results or consequences | A small portion of actions brings the majority of success, while the remaining efforts produce only a minor effect. The numbers 80 and 20 are approximate; they serve as a convenient guide rather than a strict mathematical law. |
| Murphy's Law | Law of Fick, Law of Critical Error | Anything that can go wrong will go wrong | If there is a possibility of making a mistake, it will definitely happen. This law reminds us of the need for thorough planning and creating backup action plans to minimize risks. |
| Peter Principle | Principle of Career Advancement | People tend to rise to a position beyond their competence | In a hierarchical organization, every employee tends toward promotion. Over time, each person will reach their level of incompetence — the level at which they can no longer work effectively. As a result, positions are often occupied by incompetent specialists. |
| Occam's Razor | Principle of Parsimony, Law of Simplicity | Entities should not be multiplied beyond necessity (Entia non sunt multiplicanda praeter necessitatem) | Among several possible explanations of a fact, one should choose the simplest. The fewer assumptions — the more reliable the conclusion. This principle underlies the scientific method and effective debugging. See also: Quantum Razor. |
| Dunning-Kruger Effect | Fool's Peak Effect, Self-Satisfied Beginner Syndrome | Incompetent people tend to overestimate their abilities | Incompetent people cannot recognize their own incompetence. The more someone knows, the better they understand the boundaries of their knowledge. Conversely, a beginner often considers themselves an expert due to lack of metacognitive skills. |
| Goodhart's Law | Indicator Problem, Law of Goal Substitution | When a measure becomes a goal, it ceases to be a good measure | As soon as a metric (KPI) becomes a target to achieve, it stops being a reliable indicator of reality. People begin optimizing the metric rather than the actual result, leading to distortions and manipulation. |
| Quantum Razor | Skeptics' Razor, Principle of Sufficient Proof | The strength of a claim is proportional to the strength of evidence. "Extraordinary claims require extraordinary evidence" | Carl Sagan: if someone claims something supernatural — the burden of proof is on them. In development: a new framework is "revolutionary" — show benchmarks and migration cases. See also: Occam's Razor. |
Productivity and Time Management
| Name | Alternative Name | Rule / Principle | Description |
|---|---|---|---|
| Parkinson's Law | Law of Task Expansion, Law of Deadline Inflation | Work expands to fill the time available for its completion | No matter how much time is allocated to a task, it will take all of that time. If a month is given for a project — it will take a month. If a year — it will take a year. Deadline control and strict deadlines are key to effective work. |
| Hofstadter's Law | Law of Hofstadter, Law of Multi-fold Planning Error | Work always takes longer than expected, even considering Hofstadter's Law | When planning deadlines, it is almost impossible to correctly estimate task complexity, especially in the final stages. Always add a significant time buffer to any estimate, as unforeseen difficulties will inevitably arise. |
| Decky's Law | Linear Law of Time, Law of 50% | If a task has already taken half the allotted time, it will take twice the remaining time | An evolution of Hofstadter's Law. If you've spent half the supposed time halfway to your goal — you will work twice as long as planned. Helps to timely adjust expectations and deadlines. |
| Eisenhower Matrix | Priority Matrix, Task Separation | Distribute tasks across 4 quadrants: important/urgent — unimportant / not urgent | Quadrant I: do now. II: schedule. III: delegate. IV: delete. A critical tool for fighting "fires" instead of strategic work. |
| 1–3–5 Rule | Day Planning Rule, Day Prioritization Method | Per day: 1 big + 3 medium + 5 small tasks | A realistic productivity limit: per day you can realistically complete only ~9 tasks when ranked by complexity. Prevents overload and burnout. |
| Zeigarnik Effect | Uncompleted Action Effect, Law of Unfinished Cycles | Uncompleted tasks are remembered better than completed ones | The brain "hangs" on open loops. Solution: write everything down, decompose, close. Used in task trackers and GTD methodology to reduce anxiety. |
| Law of the Last Responsible Moment | Law of Last Responsible Moment, Principle of Maximum Deferral | Don't make decisions earlier than necessary — information becomes more valuable over time | Early decisions fix options and block flexibility. Postponing until the last possible moment preserves maximum alternatives. Foundation of Agile and Lean. |
Programming and Development
| Name | Alternative Name | Rule / Principle | Description |
|---|---|---|---|
| KISS Principle | Keep It Simple, Stupid; Keep It Simple | Strive for maximum simplicity in solutions and design | Most systems work best when they are simple. There is no need to complicate where one can simplify. Simple systems are easier to maintain, debug and scale. See also: YAGNI. |
| DRY (Don't Repeat Yourself) | Don't Repeat, Single Abstract Representation Principle | Every piece of code should have one and only one representation | Any knowledge or logic in a system should be represented once. Repeating code leads to desynchronization, bugs and maintenance difficulties. Extract common logic into functions, modules or libraries. See also: Boy Scout Rule. |
| YAGNI (You Ain't Gonna Need It) | You Won't Need It, Principle of Refusing Forecasts | Don't add functionality until it is really needed | Always implement what is needed at the moment — and nothing more. Predictions about future needs are almost always wrong, and premature optimization complicates code and slows development. See also: KISS. |
| Principle of Least Astonishment | Principle of Least Astonishment (POLA), Law of Expectancy | The behavior of the system should match user expectations | API, interface or code should behave in a way that is maximally predictable and intuitive. If functionality behaves unexpectedly — this is a poorly designed system, regardless of its power. |
| Boy Scout Rule | Boy Scout Rule, Cleaning Principle | Leave the code cleaner than you found it. Every change is a mini-refactoring | Every time you make a correction, improve the surrounding code: remove duplicates, rename, simplify. Cumulative effect — eternal refactoring without a separate phase. See also: DRY. |
| Dilbert's Law | Law of Accumulated Problems, Matryoshka Effect | The number of accumulated problems grows proportionally to the number of people solving these problems | More participants = more solutions = more side effects and new problems. Scaling the team without synchronization worsens the system. |
| Test Pyramid (Mike Cohn) | Principle of Test Pyramid, Testing Hierarchy | The lower the test level — the more tests there should be; E2E tests are the pyramid's peak, very few | Balance: many unit tests → medium number of integration tests → minimum E2E. Fast feedback at a low level prevents costly regressions. |
| Broken Windows Theory (in development) | Broken Windows Theory, Code Degradation Effect | Signs of degradation attract new signs; minor "bugs" lead to systemic decline | Broken windows in a building signal: nobody cares here. In code: uncleaned TODOs, bad names, duplicates — all this lowers the team standard and accelerates degradation. |
Architecture and Design
| Name | Alternative Name | Rule / Principle | Description |
|---|---|---|---|
| Folk's Law | Law of Necessity, Folks' Formula | Don't choose a solution until you've studied all existing alternatives. "Before choosing a refusal tool — study everything that's already written" | The most famous law in software development: before writing your own solution, check if there is already a ready-made one. Related to the principle of "don't reinvent the wheel." |
| Hammer's Law | Tool Law, Hammer Effect | For every problem view in the world, there remains enough hammers. "If you have a hammer — every problem looks like a nail" | The tendency to see all problems through the prism of familiar tools and methods. Leads to suboptimal solutions: a programmer tries to "code" something that could be solved with a process or communication. |
| Gammon's Law | Acceleration Law, Moving Target | When an object's performance increases — the need for objects grows, negating the expected efficiency gain | Automating one process without optimizing others creates a "bottleneck" elsewhere. Scaling individual elements without a system yields only an illusion of improvement. |
| Conway's Theorem | Law of Architecture Correspondence, Reverse Conway Theorem | An organization designing a system must mirror the structure it reproduces. "Communication structures dictate code structure" | The product's architecture mirrors the team's architecture. If teams are divided — so will the code be a mosaic from silos. For microservices, cross-functional teams are needed. See also: Conway's Law. |
| Law of Demeter (LoD) | Principle of Least Knowledge, Law of Ignorance | "Only talk to your immediate friends" — don't access intermediate members of internal modules of other objects | Minimizing coupling: an object should know only about its direct dependencies. Reduces fragility and simplifies refactoring. |
Management and Organization
| Name | Alternative Name | Rule / Principle | Description |
|---|---|---|---|
| Conway's Law | Convergence of Architecture and Organization, Law of Communication Structures | Systems design cannot avoid the communication structures of organizations | Software architecture directly reflects the structure of the team that creates it. To improve a system's architecture, it is often necessary to restructure the team's communication flows. Divide the team — and the system will be divided too. See also: Conway's Theorem. |
| Diogenes Principle | Don't Touch What Works, Law of Non-Interference | If it works, don't fix it (If it works, don't fix it) | An existing working system is a better solution than a potentially better but unrealized one. Any change carries risks and costs — they must be strictly justified by measurable benefit. |
| Rickert's Law | Law of Mutual Arguments, Law of Counterargumentation | Every loud claim has an equally powerful counterclaim | In any debate or discussion, you can find both proponents and opponents of almost any viewpoint. This does not mean all opinions are equivalent — but it is important to seek arguments for and against to form a balanced judgment. |
| Two Pizza Rule (Amazon) | Optimal Team Size, Bezos' Law | A team should fit on two pizzas — not more than ~8 people. More — too much communication | 9 people = 36 possible connections. Effective team — 5–8 people. For scaling: divide into multiple autonomous teams with clear API contracts. Related to Conway's Theorem. |
| Shanton's Law | Team Compatibility Law, Task Distribution Principle | Tasks should be distributed across the team proportionally to their ability to solve these tasks | If one team takes on too much — they become a bottleneck. Distribute workload, considering expertise and capacity. Otherwise — overload of leaders + idling of the rest. |
General Principles and Effects
| Name | Alternative Name | Rule / Principle | Description |
|---|---|---|---|
| Placebo Effect | Reverse Placebo, Illusion of Utility Effect | Belief in the effectiveness of an impact can trigger a real physiological or psychological result | If a person believes they are receiving help — it is more likely to help. The reverse effect (nocebo) — expecting negativity can worsen symptoms even with a benign impact. Influence is strong in projects: "the recipe worked for everyone" often helps on your project too. |
| Perbon Effect | Law of Interface Degradation, Paradox of Improvements | Users do not accept system improvements if they change familiar interfaces | The better the system becomes from the developer's perspective — the less users are willing to use it if it disrupts established habits. Changes should be implemented gradually, maintaining backward compatibility and intuitiveness. |
| Halo Effect | Halo Effect, Radiant Halo Effect | General impression of a person or product distorts the assessment of their individual qualities | If an object is perceived positively overall, we tend to overestimate all its properties — even those we haven't checked. In development: a beautiful UI makes one believe in quality "under the hood," which can be misleading. |
| Framing Effect | Framing Effect, Context of Presentation Effect | The same content is perceived differently depending on the method of presentation | "95% fat-free" sounds better than "5% fat." The same code, described as "a solution to a problem" or "an additional feature," receives different reactions from the team. Context and formulations are critically important in communication. |
| Anchoring Effect | Binding Effect, Anker-Effekt | The first information received significantly influences subsequent decisions and estimates | The initial number or fact serves as an "anchor" to which all subsequent judgments are adjusted. In negotiations, the first number announced often becomes the basis for a deal. In development: the project's initial plan sets the tone for all future estimates. |
| Fundamental Attribution Error | Correspondence Effect, Correspondence Hypothesis | Tendency to explain others' behavior with internal qualities, ignoring external circumstances | If a colleague was late — we think: "they're irresponsible." If we were late — "there was traffic." We overestimate a person's character and underestimate the influence of the situation. Leads to conflicts in teams and incorrect conclusions about the causes of problems. |