alt Hacker NewsWhy Big Companies Keep Failing: The Stack Fallacy (2016)
Comments
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.
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.
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.
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.
Oh wow - interesting to see this up again. I am the author of The Stack Fallacy. #AMA
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.
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.
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.
>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.
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)
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.
This article misses the mark. It's not about knowledge, it's about competition. One direction creates a monopoly, the other creates a competitor in a competitive market.
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
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.
>>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.
This sounds like the Blub paradox in reverse ;).
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
From The Tao of Programming, chapter 3.3:
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.
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.
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.
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.