A lot of good bakeries decide to start making sandwiches. It’s an obvious value-add and adds margin. But sandwich customers are different from bakery customers, a sandwich shop has a different layout from a bakery, and making a great sandwich is a very different skill set from making great bread. So it’s not easy to stay a successful bakery and add on a successful sandwich business.
On the other hand, a great sandwich shop can pretty easily hire a baker and set up an oven to make exactly the bread that it needs to elevate its sandwiches.
I know some people that roll a pizza slice (from crust to center) to eat it. Blasphemous, and inspiring.
Some sandwiches naturally want to be eaten from the middle layer out.
Every time someone figures out how to do something that's subjectively graded at scale the definition of "great" changes because a large part of it is partly based on exclusivity and a smaller part is based on frequency/familiarity (i.e. people get sick of or discount the subjective quality of things they encounter with frequency).
The optimal quality model is for a sandwich place to contract out with a bakery for perfect bread but barring that a bakery can make great bread and ok fillings and still make decent sandwiches.
Think apple silicon at TSMC model for optimal quality results, intel model for good enough results.
The best sandwich shops will not make their own bread because it’s a lot easier to iterate without a bakery and 100 sandwiches shops can fail at relatively low cost for the one great one to shine. Capital costs on bakeries are much higher so you can’t just iterate in bulk. But you can get good enough at the bakery.
They uh, literally did, 25 years ago. Breadmaking at Subway scale requires a single large mixer, some countertop space, some proofing racks, an oven, and a few hours at certain times.
Like, lmao bakeries are tiny! They have been premier examples of small business for basically all of human history! It's something you can just drop into the morning setup if your food business has any interest at all in "fresh" ingredients or higher quality like the vast majority of small businesses try to focus on. It scales down extremely well, which is why Kitchenaide does great business in their "Pro" series of mixers.
In fact, 25 years ago, the New England grocery store chain Hannaford also had a fully functional and running in house bakery, including in their small stores. Fresh baked bread and pastries and cakes and baked goods every single day.
Both companies have switched out the process without actually switching out or removing the required hardware (they both still have the racks and ovens and still install them in new locations!) to one where the bread is made in a distribution hub and sent out frozen.
It was an easy service to offer when Americans could afford to pay for that kind of thing because most Americans had fine jobs. But Subway can't afford the labor rates for someone who genuinely knows how to make fresh bread, because they have to/want to pay absolute bargain basement labor rates. Their business cannot survive if they priced their sandwiches in line with how much they were 25 years ago, with the same quality of ingredients they had 25 years ago.
Americans can't afford to pay american labor, which means fewer americans end up getting paid good labor rates, which means those americans can afford less, which means etc etc etc.
Meanwhile executive compensation has only ballooned. Gee whiz.
Those that only sell bread and nothing else, are very few and slowly going away.
Thus maybe the other way around, as sibling comments are pointing out.
One thing is right though, many Germans think they are unique on this.
There is a different class of sports though. Schools should have sports as exercise for students, and classes on how to get better at sports.
* Sports gives Academics some funds
* Sports gives Academics brand marketing/prestige
* Academics gives Sports a moral cover for exploiting young athletes
* Academics gives Sports a pre-made core fanbase of students
There's a lot of overhead in a sandwich shop hiring a baker, then outfitting a kitchen to efficiently bake bread at scale. And how do you handle his days off, with n=1 baker?
Vs. a bakery only needs 4' of counter space to do a modest volume of basic (cold cuts & such) sandwiches. Unless it's a pretty upscale bakery, the customers will be fine with less-than-fancy sandwiches at less-than-fancy prices - those are mainly a "while I'm here" convenience. Vs. a "great sandwich" shop has to qualify as a destination.
Subway?
Though I should point out that this is not baking, but simply putting premade delivered dough into an oven. The dough is baked, yes, but this is not what people mean by baking.
A bakery generally is mixing flour themselves.
Frozen dough doesn't come out the same, nor does reheated pre-baked bread. It's fresh it just isn't made from scratch there in the store.
There's a couple dozen fresh dough facilities scattered throughout the US that serve all of these restaurants that need fresh bread, but without the cost of paying someone to mix flour locally.
The thing you buy at 6am (or 6pm, lol) was in an oven or a mixer (depending on whether the chain in question is baking on site or at the hub) at 12am that morning and on a truck at 3:30.
It's been a while since I ate there, but the bread quality was for-sure not up to "we hired a baker to elevate our sandwiches" standards.
The bakery has to become a inferior sandwich shop to make sandwiches. The sandwich shop doesn't have to become a bakery to bake just the types of bread that they need to wrap their sandwiches.
The bakery would be better off selling dough to the sandwich shop.
Yes, the core idea behind Stack Fallacy was that if you are Apple you don't need to build a better CPU than Intel for all workloads - you just need M3 for your Mac.
So yes - just one type of bread. Like Subway. Or Panera.
In my experience, one of the most reliable heuristics for finding a place that makes good sandwiches is "go to a place that's a good bakery and see if they make sandwiches".
I can't think of a time I've gotten a sandwich from a (good) bakery where the sandwich wasn't at least quite good, and frequently, very very good. On the flip side, if you just buy a sandwich from a dedicated sandwich shop? On average it will be bad. There are excellent sandwich shops, for sure, that do not bake their own bread. But there are very few bakeries that make sandwiches that do not make extremely good sandwiches. (Subway doesn't count: they are not a bakery, in that they do not sell bread or other baked goods. They only produce their disgusting "bread" to enable them to sell sandwiches).
It also strikes me that this argument is essentially the inverse of the Alan Kay line "People who are really serious about software should make their own hardware" that Apple people are always quoting.
I think perhaps the Sandwich Fallacy lacks explanatory power, because the Stack Fallacy does as well. I think if the reason why big companies consistently fail to win markets in which their customers compete was because of the points made in the post, then we would see evidence that big companies are disproprotionately successful at winning markets in which their suppliers compete, the layer _below_ them in the stack: "The bottleneck for success often is not knowledge of the tools, but lack of understanding of the customer needs." the companies that build these sandwich-filling layers are the customer, they understand this quite well, but I don't think they generally succeed at this. So there must be something else at play.
I also find the examples in the article unconvincing:
"Apple continues to successfully integrate vertically down — building chips, programming languages, etc., but again has found it very hard to go up the stack and build those simple apps — things like photo sharing apps and maps."
Apple's photo app is extremely popular. Apple's messaging app, Messages, is so compelling it continues to sell Apple's ludicrously expensive devices. It's literally a Killer App for iOS, in the Visicalc mode. Apple has been building top-tier first party applications for it's platform since the 1980s. For iOS, it's Photos, Messages, Notes, Music, and Safari (I'm not arguing that Safari isn't terrible, or that Apple isn't holding back the progress of the entire open web via failing to make progress on Mobile Safari (they are). I'm simply arguing that it's undeniably successful.) Before the mobile era it was the 'digital hub' apps like iPhoto, iMovie, Garage Band. In the 'productivity' era it was ClarisWorks. In fact, it's so common that there's a slang term for when Apple-the-platform-vendor starts to compete with it's application developers and uses its structural advantages to win the market: "Sherlocking".
"It is therefore no surprise that Apple had an easier time building semiconductor chips than building Apple Maps."
Did they? They bought PA Semi a zillion years ago. Apple Maps had a rocky launch but now it's quite good. I concede I have no evidence that it's popular or successful in the market. It looks to me like Apple was successful in both categories.
"In the 1990s, Larry Ellison saw SAP make gargantuan sums of money selling process automation software (ERP) — to him, ERP was nothing more than a bunch of tables and workflows — so he spent hundreds of millions of dollars trying to own that market, with mixed results. Eventually, Oracle bought its way into the apps market by acquiring PeopleSoft and Siebel."
I mean, sort of? Oracle is an absolutely dominant player in this market category now. They got their through the usual mix of Oracle chicanery. You know where Oracle is struggling? All the layers _below_ them.
So I think it's pretty safe to reject the Stack Fallacy and the Sandwich Fallacy. There's clearly a pattern where big companies fail to win markets of their customers as well as markets dominated by their suppliers, which is confusing given the strategic advantages they would have expanding in either direction, but I would argue that if there are common structural explanations for this, the proposed explanations are not correct.
I guess I just think it's funny that when I skimmed the initial post I just thought "hmmm, maybe?" but when I read your sandwich analogy I was like "oh, right..this doesn't make any sense. Bakeries make awesome sandwiches, almost always!" and I started thinking about it more. Whereas if you made the same point with almost any other example I would have probably been like, "yeah! This guy's right! None of the best ice cream shops are also dairies! None of the best coffee shops are also coffee farms! I've never seen a successful textile weaver start a line of pants! None of the best...tire stores...also...produce industrial rubber compounds?" I don't know. So it's a funny choice.
Google just that it was necessary and possible, not that it would be easy. I suspect that many other up-the-stack adventures by other companies were similar.
A lot of Apple’s apps predate the App Store. The apps that came later had limited use until Apple spent a lot of time refining them. Think Apple Maps.
Microsoft released Word for Mac a year before they released Windows 1.0, so Windows was “down the stack” for them.
When Google attempted their Facebook clone, it was just one of the many who took a spin at the wheel. It was always more likely to have failed than succeeded.
Building a B2C with hysteric adoption is difficult because it's very mysterious what elements of the product will actually lead to success, because it's a psychological thing. E.g., if Facebook chose green instead of blue as their theme color (all else equal), it might've died in obscurity.
Facebook hit the seam of internet 2.0: after the .com crash with a bunch of kids who grew up on AIM/ICQ/whatever and all these kids wanted to keep up with their friends at various colleges.
They indeed just got lucky.
When you're at a particular layer of the stack, you understand your immediate customer (the layer above you) reasonably well. But two layers up? Three? You're basically guessing. And the higher you go, the more the problems become messy human problems rather than clean technical ones.
I build accounting tools. The technical work is manageable - parsing bank statements, matching transactions, posting to ledgers. But understanding why a bookkeeper categorises something a particular way, or what makes a reconciliation workflow feel "right" vs frustrating - that took years of sitting with actual users and watching them work. A database company could technically build what I build in a few months. They'd never ship something anyone actually wanted to use.
I am now founder of Skyflow, we are runtime AI data security platform. This is my third startup, and previously I ran strategy for Salesforce.
The other (more important, maybe) thing the article points out is that building layer N-1 turns out to be easier, because layer N is the customer and understands those needs already.
The view of the article seems to be that companies solve problems. The way they solve problems is actually baked in to the structure of the management rather than any individual (sometimes there is an individual like a CEO with enough vision to reshape the management structure to solve new problems, although that is rare). It is also why acquisitions fail so easily - if you take an existing company and graft it under an existing management structure geared to solve some other problem then there is a lot of risk.
IBM didn't "happily" do anything of the sort. The company was undergoing multiple anti-trust investigations at the time and was trying to avoid incurring a large fine or even a structural remedy for creating a vertical monopoly.
The reason Microsoft went to the mat so hard when the government was trying to separate IE from Windows was Gates' fear that the company would end up being similarly crippled by the specter of anti-trust action from the government.
Document exchange, formats, and user editing experience have suffered due to their mixed goals and market control, this has real social cost. And with the current ‘copilot everywhere’ push we’re seeing pretty disruptive tech being hammered down a lot of throats. Mature Visual Studio features are being deprecated for subscription based off-site code gen… (which at a distance sounds like MS is struggling and needs extra development help to maintain its flagship development software, if only they had some kind of AI that could help them keep up…)
I dare say we’d be oodles better off with similar crippling fears in the board rooms of some media, energy, and tech conglomerates. The judge was right, and we missed a key chance to set a guiding example.
The Stack Fallacy (2016) - https://news.ycombinator.com/item?id=26177629 - Feb 2021 (28 comments)
Why Big Companies Keep Failing: The Stack Fallacy - https://news.ycombinator.com/item?id=10927600 - Jan 2016 (169 comments)
1) It may well be a dumb thing they do, but is this really "why big companies keep failing?" There's no real examination of this causal assertion which seems central.
2) Is it really the "stack"? That is to say, do people really assume that just the layer above them is trivial? I see engineers all the time assume that basically everything they don't understand is trivial. For example Elon Musk's famous assertion that the hyperloop is "Basically just like an air hockey table. It's not that hard". Well in turns out air hockey pucks don't need to transport people, g-forces aren't important for air hockey versus not murdering your passengers is quite important for a public transport system. Air hockey pucks don't need to breathe versus people do which makes the vacuum part quite critical and challenging especially since you have to figure out how to get people in and out without rupture. To think of it as like air hockey you are assuming that all interesting/challenging parts of the problem are trivial. To be clear: I think that this hubris is basically essential for innovation. I really don't think people would ever innovate if they worried too much about every small detail of things, but this is why a large proportion of experiments by everyone (big and small companies alike) fail. I don't think the layer above you in the stack is the important part here and the article doesn't examine whether that characteristic is important.
We’ve got plenty of smug actual engineers, we don’t need to take blame for some cosplayer’s bad behavior.
Point 2 is... neither important nor really germane. (I don't care what engineers say, and Musk isn't an engineer anyway.) The point is that people understand their customer bases, and sell to them, and then imagine that means they understand how to succeed in the business their customers are in, and... not so.
It's basically a reminder that understanding the customer is everything. No matter how good the tech is, if you don't solve the customer's problem... they aren't buying.
I didn't claim that this one pattern explains all of the failures.
It isn't so much that I think the criticism is wrong. Many people do think they could more effectively do something in a different area. But this isn't a stack thing. People are largely ignorant of a ton of work happening everywhere.
You see that ignorance quite commonly in stuff like climate activism. Young activists are convinced that nobody is working on the problem. And to be clear, it would be nice if maybe more people were working on some problems. But please don't ignore the progress made by a lot of hard work, in the meantime.
But back to "why companies keep failing." I could as easily assert that big companies fail when they stop pouring money into growing. Wouldn't be hard to build an argument that the more "funny money" is at play in a large company, the more they are stifling innovative ideas in their walls. Of course, if you pour money through leveraged debt, some day that comes due, as well.
IMO the complaints here are well-founded, but maybe some wires have gotten crossed in communication. There are many climate related companies out there (with varying levels of actual utility). People are obviously working on the problem, but the policy side is largely captured by big oil and other monied interests who would lose a lot of money if any meaningful shift away from fossil fuels were to happen.
Addressing the climate crisis using minimally subsidized market forces is way too slow to be effective at reaching even the bare minimum Paris Accords numbers. Even those policies at this point are being dismantled and called a "climate hoax". The market side work is laudable, but the climate crisis cannot be averted without a supportive policy framework.
I do a lot of activism work and the critique is typically centered on "nobody in the government is making progress on climate policy", not "nobody is doing anything at all". Though maybe we're talking to different groups of people lol
This sort of thing is usually made worse by people that are not willing to acknowledge that not all progress is definitionally good. (As an easy example, the report a few years ago that raised the idea that measurable increases in ocean temperature were from cleaner shipping got annoyingly ignored.)
Again, though, in my theme of "this isn't really stack related." This is also not activist related. People have a tendency to think the problem they are working on is more important than every other problem. Dentists tend to think oral health is the key to understanding all health. Nutritionists, the same. Managers tend to think things just need good management. It is a very common pattern.
And it is enticing because it speaks to kernels of truth. It just doesn't survive the "no panacea" test.
Then the activists would do well to demand a better government that isn't bribeable so easily.
THIS!! A Thousand Times This!
I have had many successful projects putting the coders in direct contact with the end users.
In contrast, every time a manager is inserted between the real user requirements and the code, the project descends a lower ring of endless-feature-creep hell, doubles in length, and doubles it's likelihood of failure.
Yes, managers are needed to provide some insulation from very noisy and chaotic feature requests from users, but insisting on at least some frequent time with some actual coders in contact with actual users pays massive dividends.
and our technolords telling us plebs will be technoserfs to be replaced by a.i or that everything will be built by a.i
There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"
"An operating system," replied the programmer.
The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said.
"Not so," said the programmer, "When designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design."
The warlord of Wu nodded and smiled. "That is all good and well, but which is easier to debug?"
The programmer made no reply.
Except today. Even since this was written, large cap growth funds or "blue chip" stocks have tremendously outperformed everything else, more than doubling the return of small cap value. Big companies are absolutely not failing. They're doing better than they ever have at any other time in history, granting this is the admittedly short span of human history in which we had public equity markets.
Intel was the leader. Comcast was the leader.
Yes Google and Apple have done great but its because they have made some good strategic decisions. And some (not all) of their failures of last 10 years fall sqaurely in stack fallacy.
Holy fuck, all you need is a server application, a database, HTML, JavaScript, and CSS to make a CRUD app. Seriously, that is really all you need. The problem though is that nobody trains developers any more and so you get a little bit of helpers to help the developers along, which turns out to be a mountain of bullshit that developers use to line their resumes like notes on toilet paper.
As a counter point I wrote a large single page app and then adapted it into removable modules that can be turned off from a JSON file. So, its modular, which then solves for the design goal of most modern JavaScript browser frameworks. But, it's just vanilla TypeScript. It is stupid simple to scale, extensions from one of two TypeScript interfaces without tech debt. The best part is that its fast... like completing all initial execution, rendering, and garbage collection in less than 130ms.
https://github.com/prettydiff/aphorio/blob/screenshots/paper...
So, in practice it seems you could easily replace 10 React/Angular developers with a single TypeScript developer and a series of small TypeScript interfaces. The bonus is that you get faster releases, 100% accessibility (because its mostly raw HTML instead of compiled templates), and a substantially faster product.
It's very weird. I've come into codebases at my current big co where 15 tables that all looked and acted exactly as terribly as one another (no sorting, no discernible sort, no filtering, limited page sizes, no search beyond CMD/CTRL-F)
And they were all built out one by one, every time.
What a mess, why! I consolidated everything down and am now bringing up both an App URL Param library other folks can use, a generic resource engine other folks can use, and a table engine which combines the two to give you most table functionality with a simple config and passing in the resources (We're internal tooling for small record sets so a lot can be handled on the front end since resource baseline can be assumed and customer count is low).
Even when you build things modularly people will give you grief. It's over engineered. Well, you say that, except it's testable at the unit level, easy to slide in to other use cases (which the test cases help ensure resiliancy for old and new), small, not nested, discoverable, flat, easy to read, and easy to maintain.
So sure, took a couple of extra hours of legwork up front compared to just dropping everything into a single React function as is the standard round these parts, but the benefits are clear.