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 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.”

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.

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.