[HN Gopher] Why Big Companies Keep Failing: The Stack Fallacy (2...
___________________________________________________________________
Why Big Companies Keep Failing: The Stack Fallacy (2016)
Author : bobbiechen
Score : 59 points
Date : 2026-01-06 16:53 UTC (6 hours ago)
(HTM) web link (techcrunch.com)
(TXT) w3m dump (techcrunch.com)
| dang wrote:
| Related:
|
| _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)
| grsmvg wrote:
| So many examples mentioned can be explained by network effect,
| first mover advantage, or an already saturated market, instead of
| underestimating the making of a good product.
| taeric wrote:
| I have grown to not agree with this idea. Sorta, at least.
|
| 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.
| r14c wrote:
| > You see that ignorance quite commonly in stuff like climate
| activism. Young activists are convinced that nobody is working
| on the problem.
|
| 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
| wrs wrote:
| I call it the "sandwich fallacy".
|
| 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.
| themafia wrote:
| The sandwich shop should just open next to the baker. It's okay
| to own and operate two businesses.
| pooper wrote:
| This 'sandwich fallacy' perfectly illustrates why I think
| sports should be removed from the university system.
| Universities are great 'bakeries' (centers of learning), but
| they've become bogged down trying to run massive 'sandwich
| shops' (commercial sports). It's okay for these to exist, but
| they should be independent entities so the school can focus
| on being a school.
| Terr_ wrote:
| Just musing on the flows between the Sports and Academics
| sides:
|
| * 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
| bluGill wrote:
| Spectator sports should be run by the marketing department
| at the university and judged by their ability to bring in
| future students and donations - both important things that
| sports do for marketing. Justify your existence based on
| those two or get rid of those sports. Since this is a
| marketing department thing other departments should stay
| out.
|
| 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.
| alanbernstein wrote:
| After all, what is a sandwich but a stack of food?
| dmoy wrote:
| Hmm, but you don't eat a sandwich layer by layer like you do
| with a stack.
| alanbernstein wrote:
| I think they're the same? both are built layer by layer but
| consumed in vertical chunks, right?
| tbrownaw wrote:
| > _you don 't eat a sandwich layer by layer_
|
| Some sandwiches naturally want to be eaten from the middle
| layer out.
| bell-cot wrote:
| A good generality, but I'll disagree on the bakery/sandwich
| specifics.
|
| 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.
| firstplacelast wrote:
| I agree here. I more often see bakeries selling sandwiches
| that they make in house (although no clue as to the
| volume/financials of it), but rarely (never?) see sandwich
| shops doing in-house baking. The independent ones out-source
| to a bakery and if it's a well known bakery, they will
| advertise where they get their bread.
| SoftTalker wrote:
| > rarely (never?) see sandwich shops doing in-house baking
|
| Subway?
| 7thaccount wrote:
| Don't they just heat up frozen/pre-made bread? I don't
| know...just I don't think they have enough room to be a
| real bakery. Also, corporate financials would have
| centralized that a long time ago.
| estimator7292 wrote:
| No, subway and panera do the same thing. Fresh premade
| dough is delivered every night, refrigerated. At Panera,
| a baker runs it through the oven overnight and finishes
| baking just before open. Subway throws dough in the oven
| as needed throughout the day, they have much higher
| volume.
|
| 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.
| estimator7292 wrote:
| Also Panera.
|
| 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.
| bell-cot wrote:
| From a quick web search - Subway has an often-changing
| network of contracted suppliers of frozen bread dough.
|
| 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.
| weaksauce wrote:
| Erick Schat's Bakkery in bishop is a counterpoint... great
| sandwiches from what i remember and a great bakery. though they
| operate kinda separate.
| Izikiel43 wrote:
| In europe is common for bakeries to sell sandwiches, and they
| are quite good.
| austin-cheney wrote:
| This became the most toxic part of web development... the tech
| stack. Its why I went to go do something else.
|
| 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.
| codyb wrote:
| Nobody builds anything modularly.
|
| 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.
| gchamonlive wrote:
| The article is, however, about a different kind of stack.
| roncesvalles wrote:
| Some of it could also be a plain Darwinian numbers game. Facebook
| was neither the first nor the only social media of its kind.
| There were hundreds of failed attempts at similar social media,
| counting those that died in obscurity.
|
| 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.
| irishcoffee wrote:
| Pretty sure Facebook took off because they required you to have
| a .edu address, and even then, when it first launched it wasn't
| just any .edu, the rolllout was slow. I remember people
| enrolling in 2-year schools when the regex matched on *.edu
| just so they could get an account.
|
| 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.
| seanhunter wrote:
| This is a great example of persuasive, but superficial, analysis.
|
| 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.
| bee_rider wrote:
| Your point 2 is interesting, but Musk isn't any type of
| engineer really, just a money guy that uses engineer words. It
| seems more likely that he assumes a Hyperloop would be trivial
| not because it is a simple application of some lower framework
| that he's got a deep understanding of, but because he hasn't
| been given an itemized bill for one.
| adamc wrote:
| I think you are criticizing an idea for not being a study. I
| think it's a reasonable and interesting idea, but at most it is
| something to consider, not some infallible axiom. More akin to
| "the Peter Principle" than a theorem.
|
| 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.
| dosinga wrote:
| This doesn't sound very convincing, mostly because the examples
| don't really line up with the claim. Apple supposedly struggles
| "up the stack," yet many of the best and most-used iPhone apps
| are built by Apple itself. Google is held up as failing at
| social, but YouTube is arguably the largest social network in the
| world. Oracle is described as struggling in apps, yet it's
| clearly doing just fine as a massive, profitable enterprise
| software company. And the IBM example is backwards: IBM didn't
| accidentally hand Microsoft the OS layer, it already had its own
| operating systems. In fact, Microsoft is the clearest
| counterexample here, it got big by owning the OS and then very
| successfully moved up the stack to dominate applications with
| Office.
| bee_rider wrote:
| FWIW the article is from 2016 (although, if the article was
| discovering some real underlying force it shouldn't be
| invalidated by the passage of time). Apple Maps was quite bad
| when it was released, I forget when that was exactly, but maybe
| it was recent enough in 2016 to be top-of-mind?
| hansvm wrote:
| IIRC it was released somewhere in the iPhone 4/5 transition
| (2011ish?). It was so abysmal for a road trip I took that I
| went to Android and haven't looked back (they also removed
| Google Maps for a bit, and the web version wasn't suitable).
| It wouldn't have been top of mind for me in 2016, but I
| wouldn't have been surprised at somebody telling me Apple
| maps sucked.
| trickypr wrote:
| I think a lot of your examples are flawed. Google didn't build
| the initial version of YouTube, they bought it.
|
| 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.
| cliffaust wrote:
| It's always better to just listen to your audience first before
| building. Big companies have so many layers involved to actually
| make sure that every engineer understands what the product they
| are building is really about
| nonameiguess wrote:
| It's pretty funny to see the 2016 date here. That's a few years
| after I finished grad school having doubled up in computer
| science and finance. It was nearly axiomatic at that point that
| small cap value funds were the best way to go for long-term
| investing, having outperformed all other broad options
| consistently for the past century over any time horizon longer
| than a decade.
|
| 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.
| jackfranklyn wrote:
| The sandwich fallacy comment nails it. The hard part isn't the
| building - it's the understanding.
|
| 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.
| toss1 wrote:
| >>The bottleneck for success often is not knowledge of the tools,
| but lack of understanding of the customer needs.
|
| 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.
| jkingsbery wrote:
| This isn't really just a big company problem, lots of start-ups
| fail too. It plays out a bit differently at big companies, as
| those failures tend to be more public but also done in a way that
| lets the company shuffle people around to the next project. There
| were lots of start-up companies that tried to build social
| networks or ERP systems or map applications that most people
| don't hear about.
| adamc wrote:
| Sure, in all cases, acquiring knowledge of what the (potential)
| customers want is difficult. The point of the article is that
| vendors of layer N tend to think they know what it takes to
| succeed at layer N+1, but they don't, because that customer
| base (N+2) is different.
|
| 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.
| roenxi wrote:
| Big companies also fail to keep their own markets with some
| regularity, the tech companies are built over the ruins of
| industries that solved the same problem in the days of yesteryear
| with different tools.
|
| 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.
| laughing_man wrote:
| >History is full of such examples. IBM thought nothing much of
| the software layer that ran their PC hardware layer and happily
| allowed Microsoft to own the OS market.
|
| 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.
| dzonga wrote:
| this is very relevant in this era - where you people making noise
| without results about they can build with a.i
|
| and our technolords telling us plebs will be technoserfs to be
| replaced by a.i or that everything will be built by a.i
___________________________________________________________________
(page generated 2026-01-06 23:10 UTC)