The Fallacy of Composition happens when you assume something that is true for one person, is also true for the entire population.
A trivial example looks like this: If someone stands up out of their seat at a football game, they can see better. The Fallacy would conclude that if everyone stood up, they would all be able to see better.
This is taught in every introductory macroeconomics class as the general form of the paradox of thrift (when there is a recession, you should save more to conserve your finances, but if everyone saves more, it deepens the recession). But not everyone learns economics, and not every economics student understands it deeply enough to realize: this is more common sense than it is economics.
Aside: Yes, common sense should be taught in schools, dont @ me!
Programming Languages
Developers might be more familiar with the famous Bjarne Stroustrup on managing the growth of C++:
"Individually, many (most?) proposals make sense. Together they are insanity to the point of endangering the future of C++."
If you are a fan of Guy Steele's talk on "Growing a Language" (my notes here), this may sound familiar. Java has a number type, but there are reasonable requests to add other important number types: complex numbers, rational numbers, intervals, vectors, matrices, and so on. He concludes:
"I might say “yes” to each one of these, but it is clear that I must say “no” to all of them!"
It's Everywhere
The Fallacy of Composition isn't just limited to language design:
- You commit it when you apply linear intuition to exponential growth.
- You commit it when you apply overly reductionist techniques like the 5 Why's to complex systems, failing to understand necessary but only jointly sufficient causal dependencies.
- You commit it when you find a local performance optimization and demand that it be applied at the language or framework level for the whole app.
- You commit it when you take a tangential indication of product traction and scale it up only to find it doesn't work.
- You commit the opposite when you float a shitty MVP and abandon a great idea because the shitty MVP was shitty.
By the way, a lot of TED Talk style speaking works this way - tell a personal anecdote, make that analogy to the problem you're trying to solve, introduce the first bit of halfway credible research that supports the story, applause. Ted Talks churn out Fallacies of Composition at industrial scale. If they were all true we would have achieved Nirvana by now.
Similar quotes:
"Mathematics requires a small dose, not of genius, but of an imaginative freedom which, in a larger dose, would be insanity." - Angus Rogers, via Grant Sanderson of ThreeBlue1Brown
The other day I made an offhand comment to my friend Joe about how the recent trend of Indie Maker group challenges (like his) can be counterproductive. He didn't get it right away, so I had to write this post. I think, if you took a better look at the things you believe and advise people to do, you'll find many, many more examples of the Fallacy of Composition.
Top comments (4)
Would be funny if the author gave a TED talk based on this article.
This is non-obvious a lot of the time. It's basically the fallacy that a lot of Science Fiction pokes at. Isaac Asimov's Robot novels and rules of Robotics for example. The fictional future often includes a combination of a lot of good things that are seemingly perfect but in reality, quite sensibly don't add up.
Schools really should put more emphasis on teaching basic logic causalities like this.
As for the main point of the article; I think a good example of avoiding this effect is Lua.
Quoting Roberto Ierusalimschy:
I think this statement really expresses the logical extreme of the "yes to each no to all" problem, by defaulting to "no to any" unless there's good enough reason to believe a particular change is without doubt the right decision for the language. And having used both Lua (mostly privately) and Ruby (mostly for work), I really do like how the language stability leads to a very concise and reasonable design. Ruby, for all its cool features, is also stuck with more than a few "legacy" features that turned out to not be as good a choice as it seemed at the time, despite being somewhat picky about what features to add:
So they did ignore Stroustrup after all!