title: Economy of Scope
url: https://m.facebook.com/notes/kent-beck/economy-of-scope/1041710055861858
hash_url: 90eca11ea6
Since I began paying attention to business at an improbably young age, I can remember hearing about “economy of scale”: the more of a thing you make, the cheaper it gets. Somehow, economy of scale got turned into a “more is better” religion, though, and pounded in where it doesn’t fit. Misused, economy of scale results in overproduction, waste, and detachment from genuine human needs. “People don’t want it? We’ll make so many so cheap they won’t be able to help themselves.”
I began studying lean manufacturing fifteen years ago because the parallels with software development were so striking. The making of a thing results in the thing, which we can sell for money, but it also results in feedback about the making process, feedback you can use to improve future making.
Mass production assumptions still underlie much of today’s software development. When I want to contrast mass production with lean production, I need a clear contrast to “economy of scale”. Ten years ago the phrase “economy of scope” popped into my head (I don’t know if it was original--few ideas are). The problem with the phrase is that, although I was certain it was correct, I didn’t know what it meant. After ten years of intermittent gnawing, I think I finally get it.
Mass production is founded on the assumption that the value of the things you produce is greater than the value of what you learn. As you make more, you learn more, but slowly. That’s okay, because you’re going to make millions more that will benefit from your learning. No rush.
When you reverse the proportion, when learning is more valuable than things, then economy of scale goes haywire. Putting off learning because “oh, we’ll make a million more,” no longer makes sense. The leverage is in learning, not production. You are willing to sacrifice today’s production for tomorrow’s improvement.
Economics still applies, but the tradeoff has shifted. Instead of trying to get economy of scale by going through many iterations of making per unit time, you try to get economy of--wait for it--scope, by squeezing as much learning as possible from each iteration. That’s what economy of scope is, improving learning per iteration.
Take Facebook as an example. We’ll account for value in terms of “making the world more open and connected” (I’ll discuss this in a future note). How much more open and connected was the world when the first site went up?
Hardly at all--the functionality was limited and the audience even more so. What was valuable was the learning, both about the functionality of the site and its implementation. Every increment of Facebook since then has been more valuable as a learning experience than as a creator of “open and connected”. Because we collectively learned, though, the functionality thrown out as a side effect of all this learning reaches one-and-a-half billion of the seven billion people on the planet.
Facebook’s engineering style is ridiculously inefficient when looked at through economy of scale glasses. Better planning and tracking, more coordination, and more engineering discipline would result in much lower costs. Unfortunately, this engineering utopia is unreachable because we’re building unprecedented features at unprecedented scale. The second time would be much faster, but this is the first time. We had no choice but to abandon economy of scale in favor of economy of scope. It’s not clear how we could have learned more and put it in service to this many people more efficiently than we did.
Ironically, scale is the most easily distinguishable feature of Facebook but to achieve it we had to abandon the conventional approach to scale. Optimizing for learning was the only practical path to scaling, to the fraction of people who connect through Facebook today and beyond.