斯特金定律
任何领域中，大约九成内容可能都很平庸。
显示原始英文内容
Sturgeon's Law
90% of everything is crap.
Takeaways
- It's like an extreme form of the Pareto Principle (80/20 rule). The bulk of what's being put out just isn't good, and the good stuff is the exception
- In software, there are often many features or code paths that add very little value, and the critical challenge is to find a way to maximize the high-impact 10%.
- Most new concepts or technologies fail to deliver, while the exceptional ones stand out.
Overview
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 line of code you write is gold; as a product manager, many features don't delight users.
It pairs with the idea of the 10x engineer not as someone who writes 10x more code, but as someone who identifies the 10% of work that delivers 10x value. The risk isn't the lower quality of the 90%, it's the pretense that it isn't. When a team considers all work to have the same value, it introduces more complexity and slows down.
In practice, Sturgeon's Law encourages continuous refinement, assumes there's a lot of "noise," and focuses on finding the "signal."
Examples
Consider an app with 100 features. User analytics might show that users heavily use 10 of these and the rest not at all, which is exactly what Sturgeon's Law predicts: 90% of this stuff doesn't provide significant value.
Another example: an organization may have many project ideas to develop each quarter. According to Sturgeon's Law, most of these ideas won't amount to anything, but a few will prove valuable.
In the area of code reviews, a significant amount of code has been written that is neither elegant nor required. This supports the hypothesis that less code is high-quality.
Origins
Theodore Sturgeon, a science fiction author, coined this phrase in 1957, responding to criticism that "90% of science fiction is crap." His response: "90% of everything is crap."
It was first published as "Sturgeon's Revelation" in a 1957 issue of Venture magazine.
核心含义
软件世界充满工具、框架、文章和方案，但数量不代表价值。团队需要用实际需求、维护成本、社区健康和验证结果筛选技术，而不是因为某个东西流行就采用。
这条规律也提醒我们，不要把一次糟糕的经验推广到整个技术领域。
实践例子
团队看到几十个新的前端框架，却发现真正适合当前项目的只有少数。先定义问题和评价标准，再做小范围验证，通常比追逐榜单更可靠。
来源与边界
科幻作家 Theodore Sturgeon 用这句话回应“科幻小说大多很差”的批评。它是反对以偏概全的修辞，不是可用于计算质量的统计定律。