公司为何把无能员工提拔到管理岗——Dilbert 原则的现实映射
迪尔伯特原则指出，企业往往不是直接针对绩效不佳的问题采取措施，而是将表现不佳的员工提拔到管理岗位，而这些岗位的影响力被认为对组织的危害性较小。这种讽刺之所以引人共鸣，是因为它揭示了一个根本性的缺陷：许多组织将管理职位视为工程师的默认职业路径，却未充分考虑这些员工究竟想要什么、又适合从事什么工作。 当晋升取代了问责制时，管理岗位上就会充斥着既缺乏技术公信力，又不具备领导能力的人。其结果便是做出糟糕的...
RSS: https://lawsofsoftwareengineering.com/index.xml
A collection of principles and patterns that shape software systems, teams, and decisions.
提交点赞
评论
点赞
收藏KISS (Keep It Simple, Stupid)
The KISS principle is a reminder that simplicity should be a key goal. If you can solve a problem with a 50-line script versus a complex 500-line solution, KISS favors the 50-line solution because eac...
DRY (Don't Repeat Yourself)
The idea of DRY is simple: each fact or piece of logic in your system should be expressed once and only once. If you find the same code, formula, or rule in multiple modules, you’re violating DRY. Suc...
Law of Demeter
The Law of Demeter, also known as “don’t talk to strangers” or the “principle of least knowledge,” was formulated to minimize the knowledge that any given object has about the overall system structure...
The Map Is Not the Territory
“The Map Is Not the Territory” is a mental model originating from general semantics. It encapsulates the idea that our perceptions or conceptual models of things are not the things themselves. In soft...
Confirmation Bias
We all like to be right. Confirmation bias is our mind’s way of cheating to feel right more often. Psychologically, once we form an opinion, we subconsciously filter information, noticing bits that su...
Principle of Least Astonishment
The Principle of Least Astonishment (POLA) is a general design principle in user interface design, software API design, coding, and documentation. The idea is simple: don’t surprise the user. The syst...
Hanlon's Razor
Hanlon’s Razor advises against assuming bad faith when an outcome may be due to human error or ignorance. If a commit introduces a security hole, it’s probably a mistake, not intentional sabotage. So ...
SOLID Principles
The SOLID principles are five high-level guidelines for object-oriented design: Single Responsibility (one concern per class), Open/Closed (open for extension, closed for modification), Liskov Substit...
Occam's Razor
Occam’s Razor is a problem-solving principle that reminds us that when we have multiple possible solutions, the simplest one is preferred. In software, this principle supports the KISS (“Keep It Simpl...
Dunning-Kruger Effect
The Dunning-Kruger Effect explains a gap between confidence and competence. When people know little about a domain, they lack the awareness required to judge their own ability. As a result, they overe...
Lehman's Laws of Software Evolution
Lehman’s Laws describe an unavoidable reality of long-lived software systems that operate in the real world. Such systems, business software, operating systems, and platforms, must continuously change...
Gustafson's Law
Gustafson’s Law is a principle in parallel computing that offers an optimistic view of scalability. Where Amdahl’s Law assumes a fixed problem size and concludes that speedup is limited by serial work...
Linus's Law
Linux’s open development model, releasing code early and often to the public, results in rapid bug-finding. When many people use and review a piece of software, problems become apparent to someone. Wh...
Metcalfe's Law
Metcalfe’s Law is an observation about communications networks that has been generalized to many technology ecosystems. It says that the value of a network is proportional to the square of the number ...
Sturgeon's Law
In the tech sphere, Sturgeon’s Law implies that most code or features are not necessary. Perhaps 90% of experiments or features don’t pan out, and only 10% drive real value. As an engineer, not every ...
Technical Debt
Technical debt highlights a fundamental tension in software engineering: speed vs. quality. The term helps explain to both developers and non-technical stakeholders why seemingly “done” software still...
Testing Pyramid
The pyramid is a visual metaphor: the largest level (at the bottom) is unit tests, which are fast and the most numerous. The middle layer is integration tests, fewer in number. The top is UI/end-to-en...
Pesticide Paradox
The “Pesticide Paradox” analogy comes from agriculture. When the same pesticide is used repeatedly, pests develop resistance to it. In software, the first runs of a new test suite might find many bugs...
Broken Windows Theory
The Broken Windows Theory in software was popularized by the book The Pragmatic Programmer. In a city, a broken window left unfixed signals neglect and invites more vandalism. Similarly in code, an ap...
Murphy's Law / Sod's Law
In software, Murphy’s Law is often used to explain bugs and production incidents: whatever can go wrong in code (a null pointer, a race condition, a network outage) eventually will manifest, especiall...
The Ninety-Ninety Rule
This rule quantifies the extent to which projects get stuck in the final phase. Often, teams make good progress at the start, building core functionality, which leads to optimism. Then integration, co...
Goodhart's Law
Goodhart’s Law comes from economics and is very relevant to software teams. For instance, a manager might set a target that “we must close 100 bug tickets this month.” Developers, feeling pressure, mi...
Zawinski's Law
Zawinski’s Law is a humorous observation about software evolution stating that applications continually gain features until they do everything, even things completely outside their original scope. It ...
Bus Factor
The Bus Factor highlights the human single point of failure in projects. In many software teams, one or two people might understand the legacy system, a crucial algorithm, or have all the deployment k...
The Boy Scout Rule
The Boy Scout Rule basically means: leave the code better than you found it. In practice, it’s not about doing big-bang rewrites or achieving perfection in one go. Instead, it’s about constant and inc...
Gilb's Law
Gilb’s Law responds to the paralysis that Goodhart’s Law can cause. This law asserts that even an approximate or indirect measurement is better than none. When something is essential (performance, cus...
YAGNI (You Aren't Gonna Need It)
YAGNI captures a core philosophy of agile development: don’t write code for features that haven’t been requested or aren’t immediately needed. If you’re implementing Module A and think “in the future ...
Putt's Law
Putt’s Law explains a known concept: that the best engineers aren’t in charge, and those in charge aren’t deeply knowledgeable about the technology. While not universally true, this highlights a real ...
Brooks's Law
Brooks’s Law challenges the belief that a software development effort is perfectly divisible among people. In reality, adding a person to a project incurs training costs and increases the number of co...
Postel's Law
This law says that if your server sends HTTP responses, it should format headers exactly per spec. But if your server receives an HTTP request with an uncommon header order or an unusual format, you s...
Gall's Law
John Gall observed that successful complex systems start as successful simple systems. If you attempt to create a complex system from the beginning, it usually doesn’t work because there are too many ...
The Ringelmann Effect
The Ringelmann Effect states that as more people work together, individual effort decreases. In software teams, productivity per person often declines in larger groups due to coordination overhead and...
Law of Unintended Consequences
The Law of Unintended Consequences states that outcomes are not entirely predictable. Systems have complex interdependencies and human factors that can cause surprises. Adding a new feature might unex...
Sunk Cost Fallacy
The sunk cost fallacy is a cognitive bias that challenges our decision-making. Humans irrationally value what they’ve already invested, whether money, time, or effort, even when those investments can’...
Kernighan's Law
Kernighan’s Law says that debugging requires understanding what the code actually does, which can be twice as hard as writing it. When coding, you operate with a specific mental model and full context...
Hofstadter's Law
This recursive law captures the paradox of estimation. No matter how much experience we have, projects tend to run late. Even if you say, “This might take 2x longer than I think,” it might still take ...
Parkinson's Law
This law shows a common problem with time management among developers. If a developer is given two weeks to complete a task that could be done in two days, the work will usually slow down, consuming m...
Premature Optimization (Knuth's Optimization Principle)
Knuth’s Optimization Principle captures a fundamental trade-off in software engineering: performance improvements often increase complexity. Applying that trade-off before understanding where performa...
Conway's Law
Conway’s Law states that software systems reflect the communication structure of the organization that builds them. A company with separate frontend, backend, and database departments will likely prod...
Amdahl's Law in Software Engineering
As you add CPU cores, only the parallelizable fraction of your code speeds up. The sequential fraction remains unchanged and eventually dominates total execution time. If “s” is the sequential fractio...