21 ms·

Why’s that company so big? I could do that in a weekend (2016)

98 points by __natty__ 3y ago

__natty__ 3y ago
Previous discussion: https://news.ycombinator.com/item?id=12626314 https://news.ycombinator.com/item?id=12626314 Why's that company so big? I could do that in a weekend (danluu.com) 712 points | 423 comments
corobo 3y ago
"Go on then" or "Yeahh, but you won't" if you're in a grumpy mood. The difference between being able and doing is infinite.
- mattgreenrocks 3y ago
  The gap from zero to one is infinitely enormous. Thus the pain of creating something new.
  - Gigachad 3y ago
    What is this comment meant to mean?
    - mattgreenrocks 3y ago
      Making something from scratch always entails a ton of effort vs improving something that exists already.
jschveibinz 3y ago
https://www.otmonline.org/post/10-idea-90-execution https://www.otmonline.org/post/10-idea-90-execution 10% idea, 90% execution. Writing code over a weekend is the “idea” only. The rest of the work takes years of disciplined execution.
- jrm4 3y ago
  Sometimes, but lets not pretend that the other 90% couldn't also be "luck," or something like "exclusive access," etc.
  - desiarnezjr 3y ago
    Luck in my experience, is really hard work. Getting to a place you can leverage opportunities really, but yeah.
    - jmcqk6 3y ago
      I think the important thing is that that Luck can often be an outcome of hard work, but hard work does not necessarily lead to luck. The world is full of people that worked really, really hard on something and failed to achieve the specific goal they set out for. Success is complicated.
    - jrm4 3y ago
      I can assure that your experience isn't representative; probably not in "big" enough spaces. It's deeply ironic, but the bigger you go, the more you can easily see luck as a factor (e.g. daddy's money)
      - desiarnezjr 3y ago
        The hard work I'm referring to is all the effort to get to place where you have even be "lucky" or serendipitous. For example, professional networking is a tremendous amount of work. But in meeting, bonding and potentially working with those people opens so many possibilities for serendipity / luck what have you. Sure there are those with Daddy's money, but more importantly the relationships, networks and resources that Daddy has are more important than just the cash. Nepotism, sure, but that's how the society has pretty much always worked.
    - selcuka 3y ago
      Working hard works better if you are lucky in the first place. You need to work much harder than the lucky ones to leverage opportunities if you were born in a third world country, or when you are physically disabled, or simply if your parents aren't wealthy.
chiefalchemist 3y ago
"What does Jimmy Page do? I can play that riff myself?" Hindsight is 20/20. And there's plenty more to product than the build. Put another way, and I say this often: "Making it look easy is very very hard." If only more fools understood this, there'd be less fools.
swader999 3y ago
Sometimes you can. Plenty of Fish, Craigslist?
dekhn 3y ago
Ah yes, a variant of the "Why don't you just..." (insert trivial, wrong solution to hard problem here)
macities 3y ago
Meh. It's much better to have the attitude in the title than to follow the article's long-winded road towards demotivation.
- mattgreenrocks 3y ago
  The happy medium is keeping the dismissive attitude out of the comment section and instead focused on actually building things.
  - wnc3141 3y ago
    A sort of build the thing approach, then worry about all the complexity that comes with scale.
keithwhor 3y ago
This article leaves out the big "D": Distribution. Google was a far superior product at the time they launched. They captured lightning in a bottle and participated in - and accelerated - a big inflection point of internet adoption; the web went from nerds to mainstream as the younger, web-native generation grew up. The technology is relevant insofar as it gave them an insurmountable lead at the time they had it. Re-creating the initial search technology itself pales in comparison to re-creating the initial conditions that allowed Google to reach millions, and then billions, of internet users in a relatively short timeframe.
RajT88 3y ago
I worked for InstallShield for a while, and had customers routinely say, "I could build a better installer in a weekend than InstallScript / Windows Installer / Whatever". I always just sort of rolled my eyes, due to the complexity I was aware of across the (many) features of any given installation engine. It's a long story as to why, but I actually ended up building an installer engine in Powershell some years later. I can now officially say all those people are morons, and you definitely should not in this day and age be rolling your own installer engine.
- didntcheck 3y ago
  Out of interest, what are some of the pitfalls or hidden requirements that people rolling their own didn't anticipate?
  - RajT88 3y ago
    Maintaining state for uninstall is a big one which comes to mind. Reference counting (which could sort of be rolled into the above item), to make sure you're not removing something someone else is using, if you install stuff to a shared location. Silent installation. Yes, this is an afterthought for a lot of devs, but a lot of techs expect it for rolling out software. Extensibility / Customization at install time. Also ties into the previous one (how to configure the install with no UI running). Resume-after-reboot functionality, to update files which may have been locked. Publishing accurate information into Add/Remove Programs (or "Programs and Features" as they call it these days). Handling elevation in cases where the user isn't Admin (or post Vista - the installer is launched under the non-admin token). "Repair" functionality, which requires maintaining the currently installed state and configuration. Support for packing up and deploying redistributables (maybe even download support). You start adding all that stuff up, and you realize - you can't bang that out in a weekend. It's a LOT of work actually.
    - bombcar 3y ago
      You forgot "not deleting C:/Program Files/" - like Sierra Utilities (un)installer. https://groups.google.com/g/alt.games.half-life/c/15MUk17ppHM https://groups.google.com/g/alt.games.half-life/c/15MUk17ppH...
tootie 3y ago
Obviously he's right on this, at least mostly right. The zero interest era fueled a VC-dominated boom where headcount was erroneously used as a proxy for scale by a lot of places. And I think the dream of a lot of people saying "let's build a better twitter" or whatever is assuming a utopian ideal where that "better twitter" is not chasing a multi-billion dollar valuation but rather trying to sustain itself for public benefit. And really, that's not crazy since Wikimedia Foundation claims 220 FTEs running one of the world's most vital services and doing so based purely on donations. That leads to other reason build a better twitter/google/facebook is so hard and that is acquiring and retaining the millions of users needed to make your platform valuable. Even a perfect product can't guarantee that will happen.
andrewstuart 3y ago
Here's a recent discussion on HN: "Microsoft could whip up paint.net in 1 day." https://news.ycombinator.com/item?id=37559256#37560257 https://news.ycombinator.com/item?id=37559256#37560257
rich_sasha 3y ago
I often wonder this too, but... I think making "another Google" is not the best example. I think it's hard to argue (although some people clearly did) that making a search engine is easy. You need to index all of Internet, cache it maybe too, rank stuff, filter out spam, work over different languages, do something about images, parse a lot of (broken) HTML, maybe run some js to figure out what a dynamic page should show, then serve it up super quickly... google is faster than pinging a local (!) NFS server at my work. But then I remember a comparison on HN about how booking.com is O(50) people and Airbnb is O(2000) total. Or I remember the total headcounts at Twitter, an app that lets you post very short messages. Or LinkedIn, a vast company with a very subpar UX, basically an inferior clone of a dozen of other social networking sites, only kept afloat by its network/monopoly effect. I mean, searching for people by name barely works! You're better off using Google to look for people on LI that its own search box! No doubt it's just my cognitive limitation, like I can't visualize the vastness of the Cosmos, but this is a close second.
- bsder 3y ago
  I agree but for a different reason. Making a search engine that is good is actually a reasonable task as shown here on HN. It doesn't seem to take very many people, either. Google has set the bar really low. By contrast, making a search engine that is monetizable and good seems to be an impossible task.
- Sohcahtoa82 3y ago
  > I often wonder this too, but... I think making "another Google" is not the best example. 100% agreed. They really should have used Twitter as an example. Any competent full-stack developer could probably have a working clone of Twitter running in a weekend. The challenge I think is scaling it to millions of daily active users. But, even then, Twitter has been around for over 10 years. The scaling problem seems to have been solved. I would think that these days, Twitter engineering would just be a whack-a-mole of odd obscure bugs. I can't think of any useful new features it's gotten in the last two years. Why do they still need so many engineers?
  - liquidpele 3y ago
marginalia_nu 3y ago
Hold my beer.
jrm4 3y ago
But lets be clear -- the idea that "big company MUST have lots of valid underlying work/complexity/effort" is definitely BS. Luck does happen, sometimes people miss seemingly obvious ideas.
- summerlight 3y ago
  > "big company MUST have lots of valid underlying work/complexity/effort" Almost 99% of the cases this is true. The question is whether this complexity is actually valuable or just accidental one accrued from path dependency.
  - jrm4 3y ago
    Yeah, that's what I was trying to get at with "valid."
    - summerlight 3y ago
      Lots of works are actually valid in that if someone doesn't do their job then those big corps will lose more money than their salary. Of course, the whole situation is far from the optimal and they could make it much more efficient with a magic wand but usually we don't have that so it takes years to improve the situation. Of course, someone (like Elon) might believe that they have such magic wand, but Twitter is losing more money than ever so probably it was not the case...
  - Qwertious 3y ago
    This is getting towards the topic of bullshit jobs. (I'm going to rip off Graber's book here.) There are several "invalid jobs", including: Flunkies - people hired to make their boss look important, because said boss has a lot of staff in their department. Their purpose is ultimately managerial infighting, which is zero-sum. Duct tapers - people whose job is to inefficiently work around problems caused by solvable social issues, e.g. a person whose job is printing out emails because $EXEC is old and refuses to learn how computers work. Box-tickers - people whose job isn't to do something, but to be seen doing something, so that company can claim they're trying to do X when they don't give a shit about actually accomplishing X. I'm skipping the others, because I don't understand them well enough to explain them in my own words.
rozap 3y ago
The author took probably the dumbest and most egregious instance of this ("I can replace google with lucene!") and completely sidesteps the legit discussion that often happens in the face of this absurdity. Why does it take hundreds of facebook engineers to make instagram completely nonfunctional, when the original company had created a nice product with a dozen engineers? Seems like the answer is in the ulterior motives of the company, and the centralization and decline of the internet in general. But it still feels absolutely absurd on the outside looking in and the underlying reasons are somewhat interesting, though usually not technical. There are reasonable discussions of this sort, but the example OP goes on about is kind of a straw man. Just because anyone can go on the internet and say anything ("I'll build google in a weekend!") doesn't mean it needs a whole rebuttal that takes it seriously. edit: just realized this was 2016. a purer time.
- HWR_14 3y ago
  The answer for IG seems somewhat easy. It takes as much work for a UX designer to design the French translation as the [very minor language] translation. Or financial disclosure requirements in Germany vs Andorra. Each employee serves fewer people (assuming you start in the biggest regions). The same logic applies to bugs on more and more obscure setups, or more and more niche features.
- hinkley 3y ago
  It takes raw talent or many hands to make something completely nonfunctional. With a small team someone might accidentally do something coherent. In a large team there’s no danger of that. Unless one or two people somehow wrangle control of the whole thing.
Almondsetat 3y ago
OpenAI has made a better product than Google with less time and engineers Stable Diffusion has made a state of the art software with less time and engineers than OpenAI Let's stop talking about hypotheticals, the examples are many
- scubbo 3y ago
  > OpenAI has made a better product than Google with less time and engineers Google has its flaws; but this is manifestly false _even_ if you restrict "Google" to just Search.
  - Almondsetat 3y ago
    It's true if you restrict google to just Bard
    - d-lisp 3y ago
      I would be curious to know how the team working on Bard is organized.
- ugh123 3y ago
  If OpenAI can run its product for billions of queries a day supported by just ad revenue, then i'd believe you. Both are fantastic, but not the same.
- colinmorelli 3y ago
  Building something _different_ faster/cheaper than a competitor is not really the same as rebuilding the same thing with a fraction of the people. In the past when I've seen the claim "I could rebuild this in a weekend" it's literally calling into question why so many engineers were needed to build _that thing_, not something else. More specifically, new entrants (and especially so in new categories) regularly get the luxury of extended time to iron out issues, create a better UX, find all the edge cases, invest in internationalization, distribute to multiple platforms, integrate with other systems, address security issues, and more. These tend to be exactly the kind of things that make recreating the incumbent products hard. If OpenAI continues on its current trajectory, it can easily end up with a team equal to or larger in size than all of Google working on search.
roenxi 3y ago
The first moat is usually capital expenses. Look at AWS - they're built mainly on open source software so it is obviously trivial to re-implement a lot of their core functionality. But it is hard to compete with the sheer amount of capital. The software aspects make a big difference too, but it is actually quite easy to re-implement software. Something like git for example was built rapidly (3 months?) after a few years of using other VCS to learn what it needed to do.
ChrisMarshallNY 3y ago
I get that all the time. In my experience, there's a huge difference between "software that works," and "software that ships." Most of my test harnesses are full-fat applications. They are written in a ship fashion, but they don't have the polish and TLC that I lavish on the ship stuff. I can write a test harness app in a day or two. It will be a fully-functional, accessible, localizable app, with a non-trivial feature set. However, if I write something to ship, it may take a couple of months (or longer). An example is the app I'm writing now. I wrote the "heart" library in about a month and a half. It has a test harness that runs every feature, and the test harness was the largest part of the job. However, the ship app is coming to beta, about a year later. It knocks the test harness into a cocked hat.
- ActorNightly 3y ago
  There is definitely an aspect of raw time that needs to be put into development to make a prod version of software robust, but that still doesn't account for the bloat. The real issue for the bloat is simple lack of engineering skill. Most "engineers" have very little clue of what goes on under the hood when their code is running, and really only rely on learned patterns to complete their job. So many times I have been given code for a service that when run locally doesn't work, with the explanation that you have to test it in beta stage - the reason this happens is because nobody who started writing that code has any idea of what goes on outside of the boilerplate that is provided for them to fill in.
scifi 3y ago
Have you ever seen a modernist piece of art sell for a bunch of money? There's almost always someone who offers "I could do that". But they cannot. And they will not. It is a statement made to demean others and elevate the self.
- geraldwhen 3y ago
  Art sales are obvious money laundering. The only way to compete on price would be to have a connection with someone trying to launder money.
  - dharmab 3y ago
    Art sales are typically for tax reasons, not money laundering.
Freedom2 3y ago
I'm often reminded of a famous anti-Dropbox comment somewhere, but a lot of the time it's about the right product at the right time with the right marketing.
tqi 3y ago
I think people on both sides of this debate are being obtuse. As we've seen from the rounds and rounds of layoffs over the last 18 months, most big companies were (probably) bigger than they needed to be to function (TBD on X). However it's silly to point to something like Instagram and think "they built something great with 12 ppl, what are all these other thousands of people even doing?" An app used by 1B+ people is more than 10X more complicated than an app that is used by 100M people.
crabmusket 3y ago
> This reminds me of a common fallacy we see in unreliable systems, where people build the happy path with the idea that the happy path is the “real” work, and that error handling can be tacked on later. For reliable systems, error handling is more work than the happy path. The same thing is true for large services -- all of this stuff that people don't think of as “real” work is more work than the core service. This is a fantastic point.
mo_42 3y ago
I guess the simple answer would be: No, first seek to understand. Given this principle, we would mostly realize that even if it was that simple, the business is still years ahead because those people don't just come to work to drink coffee. However, I'd like to point out that there are rare cases when some newcomers can replace existing businesses because they found some technology that simply replaces years of work.
Animats 3y ago
When Cuil [1] did a search engine back in 2008-2010, one of the ex-Google people there told me that the core team that did the Google search engine was under 100 people. It's become more complex since then, of course, but the core search engine isn't using up most of Google's work force. If you did it today, you'd probably want a fairly literal-minded search engine front-ended by a large language model to make it more user-friendly. That might be easier than trying to make the core search engine appear semi-intelligent. [1] https://en.wikipedia.org/wiki/Cuil https://en.wikipedia.org/wiki/Cuil
- gardenhedge 3y ago
  I remember Cuil.. being awful. How did they launch when it was so bad?
  - Animats 3y ago
    Because they were trying to convince the VCs it was going to work. That was unsuccessful; they ran out of funding. The principals were then re-hired by Google.
    - gardenhedge 3y ago
      > The principals were then re-hired by Google. That is shocking!
alexmolas 3y ago
I don't know if "add engineers until the cost of adding an engineer equals the revenue gain plus the cost savings at the margin" is a good idea. A lot of companies did that before/during the pandemic, and after that they had to layoff thousands of people. Under the assumption that your market will always increase it makes sense tho, but that's a huge assumption.
jillesvangurp 3y ago
A lot of hard problems actually become harder with more people. Now you are not only dealing with the problem itself but also with the problem of getting people to agree your solutions are worth the trouble. Cat herding is much harder than innovation. I've built a few products with a skeleton team. You can move really quickly on a lot of issues if you have the right people. And let's face it, a lot of successful companies are not exactly rocket science in terms of what they come up with. Slack: middle of the road chat thingy. Their UX is nice and cute but otherwise there isn't a whole lot of special stuff going on. There are a gazillion alternatives that do more or less the same thing. Airbnb. Cute idea but it's a glorified market place. Twitter has some interesting tech related to scaling search but otherwise it's basically a fast version of mastodon, which is community supported. And they weren't all that fast or scalable initially (fail whale?!). There are a lot of tech companies where the tech is pretty middle of the road. A lot of these companies actually established themselves with much smaller teams than they currently have. My theory is that they actually could not have done it with a bigger team. You need a small and focused team to get results. That's why startups are a thing. Large companies with way more resources struggle to do the same things that small, nimble teams of less than 10 people accomplish. A lot of these big companies established themselves before they bloated their teams; not after. Google was a handful of graduate students that built a nice search engine and ran circles around their competition. They were smart, not big. To move quickly, you need a good team that is not burdened by design by committee style management. Google seems paralyzed lately actually. I'm not sure they'd be able to build another search engine. Plenty of talent and money but their ability to focus all that on anything has gone down the drain.
crvdgc 3y ago
True to a certain extent. Being good at execution is both a blessing and a curse. Nowadays, it's just a matter of time before a product's anti-features catch up with its features. Then only implementing the features would get you ahead.
drt5b7j 3y ago
Found the answer, saved you having to read the whole thing > Businesses should keep adding engineers to work on optimization until the cost of adding an engineer equals the revenue gain plus the cost savings at the margin. This is often many more engineers than people realize. But it's well written, do read it.
Mekulpa 3y ago
People don't scale. It takes a team college a few hours to analyze a bug or to write a new feature or upgrade something for security etc. A week goes by so fast. The last 20% are just what they are.
eviks 3y ago
So how do these arguments help answer whether any criticism of a particular company's size is justified? You could say exactly the same things whether a company employs 10 engineers to tackle no-space-separated Chinese or a 1000
infomiho 3y ago
Off-topic but: body { max-width: 80ch; margin: 2rem auto; font-size: 18px; line-height: 1.5; }
dasil003 3y ago
Whenever these discussions come up, a large contingent of commenters talks about how much headcount a company or product “needs”. But that’s not how growing tech companies are resourced. They hire based on what they can afford, in order to maximize growth. This leads to decreasing efficiency, especially if they don’t have the right technology leadership that knows how scale tech teams, but gives them optionality to chase many new growth directions. As long as the growth continues though, no one is too concerned about efficiency at this stage. It’s only later when the growth slows, that the questions come about how many heads are really needed (and what to do about the unmaintainable state of the systems)
dreamcompiler 3y ago
This article made me think of painting. As in painting the walls of your living room. Looks easy. How hard could it be? Turns out painting is easy if you don't care if it looks like crap when you're done. But if you want it to look good, you'll spend 90% of your time on prep: Moving out or covering the furniture, laying down and securing a tarp on the floor, taking down all the pictures, scrubbing the walls clean, patching holes in the drywall and retexturing, and then carefully masking around the edges of the walls with tape. 90% of the remainder of the time is stirring your paint and carefully painting around all the edges with a trim brush, going extra slow wherever there's a moulding edge that couldn't be masked. There are tricky roller guides that make this faster, but it's still easy to make a mess that requires laborious correction. If you screw up these edges they will ruin the appearance of the room. The next bit of the job is rolling on the big areas of paint in the middle of the wall, which is what everybody sees first. That only takes 5 minutes. Then finally you spend a couple of hours cleaning everything up and replacing the furniture. How hard could it be, indeed.

98 points by __natty__ 3y ago

Previous discussion: https://news.ycombinator.com/item?id=12626314 https://news.ycombinator.com/item?id=12626314 Why's that company so big? I could do that in a weekend (danluu.com) 712 points | 423 comments

corobo 3y ago

"Go on then" or "Yeahh, but you won't" if you're in a grumpy mood. The difference between being able and doing is infinite.

mattgreenrocks 3y ago
The gap from zero to one is infinitely enormous. Thus the pain of creating something new.
- Gigachad 3y ago
  What is this comment meant to mean?
  - mattgreenrocks 3y ago
    Making something from scratch always entails a ton of effort vs improving something that exists already.

jschveibinz 3y ago

https://www.otmonline.org/post/10-idea-90-execution https://www.otmonline.org/post/10-idea-90-execution 10% idea, 90% execution. Writing code over a weekend is the “idea” only. The rest of the work takes years of disciplined execution.

jrm4 3y ago
Sometimes, but lets not pretend that the other 90% couldn't also be "luck," or something like "exclusive access," etc.
- desiarnezjr 3y ago
  Luck in my experience, is really hard work. Getting to a place you can leverage opportunities really, but yeah.
  - jmcqk6 3y ago
    I think the important thing is that that Luck can often be an outcome of hard work, but hard work does not necessarily lead to luck. The world is full of people that worked really, really hard on something and failed to achieve the specific goal they set out for. Success is complicated.
  - jrm4 3y ago
    I can assure that your experience isn't representative; probably not in "big" enough spaces. It's deeply ironic, but the bigger you go, the more you can easily see luck as a factor (e.g. daddy's money)
    - desiarnezjr 3y ago
      The hard work I'm referring to is all the effort to get to place where you have even be "lucky" or serendipitous. For example, professional networking is a tremendous amount of work. But in meeting, bonding and potentially working with those people opens so many possibilities for serendipity / luck what have you. Sure there are those with Daddy's money, but more importantly the relationships, networks and resources that Daddy has are more important than just the cash. Nepotism, sure, but that's how the society has pretty much always worked.
  - selcuka 3y ago
    Working hard works better if you are lucky in the first place. You need to work much harder than the lucky ones to leverage opportunities if you were born in a third world country, or when you are physically disabled, or simply if your parents aren't wealthy.

chiefalchemist 3y ago

"What does Jimmy Page do? I can play that riff myself?" Hindsight is 20/20. And there's plenty more to product than the build. Put another way, and I say this often: "Making it look easy is very very hard." If only more fools understood this, there'd be less fools.

swader999 3y ago

Sometimes you can. Plenty of Fish, Craigslist?

dekhn 3y ago

Ah yes, a variant of the "Why don't you just..." (insert trivial, wrong solution to hard problem here)

macities 3y ago

Meh. It's much better to have the attitude in the title than to follow the article's long-winded road towards demotivation.

mattgreenrocks 3y ago
The happy medium is keeping the dismissive attitude out of the comment section and instead focused on actually building things.
- wnc3141 3y ago
  A sort of build the thing approach, then worry about all the complexity that comes with scale.

keithwhor 3y ago

This article leaves out the big "D": Distribution. Google was a far superior product at the time they launched. They captured lightning in a bottle and participated in - and accelerated - a big inflection point of internet adoption; the web went from nerds to mainstream as the younger, web-native generation grew up. The technology is relevant insofar as it gave them an insurmountable lead at the time they had it. Re-creating the initial search technology itself pales in comparison to re-creating the initial conditions that allowed Google to reach millions, and then billions, of internet users in a relatively short timeframe.

RajT88 3y ago

I worked for InstallShield for a while, and had customers routinely say, "I could build a better installer in a weekend than InstallScript / Windows Installer / Whatever". I always just sort of rolled my eyes, due to the complexity I was aware of across the (many) features of any given installation engine. It's a long story as to why, but I actually ended up building an installer engine in Powershell some years later. I can now officially say all those people are morons, and you definitely should not in this day and age be rolling your own installer engine.

didntcheck 3y ago
Out of interest, what are some of the pitfalls or hidden requirements that people rolling their own didn't anticipate?
- RajT88 3y ago
  Maintaining state for uninstall is a big one which comes to mind. Reference counting (which could sort of be rolled into the above item), to make sure you're not removing something someone else is using, if you install stuff to a shared location. Silent installation. Yes, this is an afterthought for a lot of devs, but a lot of techs expect it for rolling out software. Extensibility / Customization at install time. Also ties into the previous one (how to configure the install with no UI running). Resume-after-reboot functionality, to update files which may have been locked. Publishing accurate information into Add/Remove Programs (or "Programs and Features" as they call it these days). Handling elevation in cases where the user isn't Admin (or post Vista - the installer is launched under the non-admin token). "Repair" functionality, which requires maintaining the currently installed state and configuration. Support for packing up and deploying redistributables (maybe even download support). You start adding all that stuff up, and you realize - you can't bang that out in a weekend. It's a LOT of work actually.
  - bombcar 3y ago
    You forgot "not deleting C:/Program Files/" - like Sierra Utilities (un)installer. https://groups.google.com/g/alt.games.half-life/c/15MUk17ppHM https://groups.google.com/g/alt.games.half-life/c/15MUk17ppH...

tootie 3y ago

Obviously he's right on this, at least mostly right. The zero interest era fueled a VC-dominated boom where headcount was erroneously used as a proxy for scale by a lot of places. And I think the dream of a lot of people saying "let's build a better twitter" or whatever is assuming a utopian ideal where that "better twitter" is not chasing a multi-billion dollar valuation but rather trying to sustain itself for public benefit. And really, that's not crazy since Wikimedia Foundation claims 220 FTEs running one of the world's most vital services and doing so based purely on donations. That leads to other reason build a better twitter/google/facebook is so hard and that is acquiring and retaining the millions of users needed to make your platform valuable. Even a perfect product can't guarantee that will happen.

andrewstuart 3y ago

Here's a recent discussion on HN: "Microsoft could whip up paint.net in 1 day." https://news.ycombinator.com/item?id=37559256#37560257 https://news.ycombinator.com/item?id=37559256#37560257

rich_sasha 3y ago

I often wonder this too, but... I think making "another Google" is not the best example. I think it's hard to argue (although some people clearly did) that making a search engine is easy. You need to index all of Internet, cache it maybe too, rank stuff, filter out spam, work over different languages, do something about images, parse a lot of (broken) HTML, maybe run some js to figure out what a dynamic page should show, then serve it up super quickly... google is faster than pinging a local (!) NFS server at my work. But then I remember a comparison on HN about how booking.com is O(50) people and Airbnb is O(2000) total. Or I remember the total headcounts at Twitter, an app that lets you post very short messages. Or LinkedIn, a vast company with a very subpar UX, basically an inferior clone of a dozen of other social networking sites, only kept afloat by its network/monopoly effect. I mean, searching for people by name barely works! You're better off using Google to look for people on LI that its own search box! No doubt it's just my cognitive limitation, like I can't visualize the vastness of the Cosmos, but this is a close second.

bsder 3y ago
I agree but for a different reason. Making a search engine that is good is actually a reasonable task as shown here on HN. It doesn't seem to take very many people, either. Google has set the bar really low. By contrast, making a search engine that is monetizable and good seems to be an impossible task.
Sohcahtoa82 3y ago
> I often wonder this too, but... I think making "another Google" is not the best example. 100% agreed. They really should have used Twitter as an example. Any competent full-stack developer could probably have a working clone of Twitter running in a weekend. The challenge I think is scaling it to millions of daily active users. But, even then, Twitter has been around for over 10 years. The scaling problem seems to have been solved. I would think that these days, Twitter engineering would just be a whack-a-mole of odd obscure bugs. I can't think of any useful new features it's gotten in the last two years. Why do they still need so many engineers?
- liquidpele 3y ago

marginalia_nu 3y ago

Hold my beer.

jrm4 3y ago

But lets be clear -- the idea that "big company MUST have lots of valid underlying work/complexity/effort" is definitely BS. Luck does happen, sometimes people miss seemingly obvious ideas.

summerlight 3y ago
> "big company MUST have lots of valid underlying work/complexity/effort" Almost 99% of the cases this is true. The question is whether this complexity is actually valuable or just accidental one accrued from path dependency.
- jrm4 3y ago
  Yeah, that's what I was trying to get at with "valid."
  - summerlight 3y ago
    Lots of works are actually valid in that if someone doesn't do their job then those big corps will lose more money than their salary. Of course, the whole situation is far from the optimal and they could make it much more efficient with a magic wand but usually we don't have that so it takes years to improve the situation. Of course, someone (like Elon) might believe that they have such magic wand, but Twitter is losing more money than ever so probably it was not the case...
- Qwertious 3y ago
  This is getting towards the topic of bullshit jobs. (I'm going to rip off Graber's book here.) There are several "invalid jobs", including: Flunkies - people hired to make their boss look important, because said boss has a lot of staff in their department. Their purpose is ultimately managerial infighting, which is zero-sum. Duct tapers - people whose job is to inefficiently work around problems caused by solvable social issues, e.g. a person whose job is printing out emails because $EXEC is old and refuses to learn how computers work. Box-tickers - people whose job isn't to do something, but to be seen doing something, so that company can claim they're trying to do X when they don't give a shit about actually accomplishing X. I'm skipping the others, because I don't understand them well enough to explain them in my own words.

rozap 3y ago

The author took probably the dumbest and most egregious instance of this ("I can replace google with lucene!") and completely sidesteps the legit discussion that often happens in the face of this absurdity. Why does it take hundreds of facebook engineers to make instagram completely nonfunctional, when the original company had created a nice product with a dozen engineers? Seems like the answer is in the ulterior motives of the company, and the centralization and decline of the internet in general. But it still feels absolutely absurd on the outside looking in and the underlying reasons are somewhat interesting, though usually not technical. There are reasonable discussions of this sort, but the example OP goes on about is kind of a straw man. Just because anyone can go on the internet and say anything ("I'll build google in a weekend!") doesn't mean it needs a whole rebuttal that takes it seriously. edit: just realized this was 2016. a purer time.

HWR_14 3y ago
The answer for IG seems somewhat easy. It takes as much work for a UX designer to design the French translation as the [very minor language] translation. Or financial disclosure requirements in Germany vs Andorra. Each employee serves fewer people (assuming you start in the biggest regions). The same logic applies to bugs on more and more obscure setups, or more and more niche features.
hinkley 3y ago
It takes raw talent or many hands to make something completely nonfunctional. With a small team someone might accidentally do something coherent. In a large team there’s no danger of that. Unless one or two people somehow wrangle control of the whole thing.

Almondsetat 3y ago

OpenAI has made a better product than Google with less time and engineers Stable Diffusion has made a state of the art software with less time and engineers than OpenAI Let's stop talking about hypotheticals, the examples are many

scubbo 3y ago
> OpenAI has made a better product than Google with less time and engineers Google has its flaws; but this is manifestly false _even_ if you restrict "Google" to just Search.
- Almondsetat 3y ago
  It's true if you restrict google to just Bard
  - d-lisp 3y ago
    I would be curious to know how the team working on Bard is organized.
ugh123 3y ago
If OpenAI can run its product for billions of queries a day supported by just ad revenue, then i'd believe you. Both are fantastic, but not the same.
colinmorelli 3y ago
Building something _different_ faster/cheaper than a competitor is not really the same as rebuilding the same thing with a fraction of the people. In the past when I've seen the claim "I could rebuild this in a weekend" it's literally calling into question why so many engineers were needed to build _that thing_, not something else. More specifically, new entrants (and especially so in new categories) regularly get the luxury of extended time to iron out issues, create a better UX, find all the edge cases, invest in internationalization, distribute to multiple platforms, integrate with other systems, address security issues, and more. These tend to be exactly the kind of things that make recreating the incumbent products hard. If OpenAI continues on its current trajectory, it can easily end up with a team equal to or larger in size than all of Google working on search.

roenxi 3y ago

The first moat is usually capital expenses. Look at AWS - they're built mainly on open source software so it is obviously trivial to re-implement a lot of their core functionality. But it is hard to compete with the sheer amount of capital. The software aspects make a big difference too, but it is actually quite easy to re-implement software. Something like git for example was built rapidly (3 months?) after a few years of using other VCS to learn what it needed to do.

ChrisMarshallNY 3y ago

I get that all the time. In my experience, there's a huge difference between "software that works," and "software that ships." Most of my test harnesses are full-fat applications. They are written in a ship fashion, but they don't have the polish and TLC that I lavish on the ship stuff. I can write a test harness app in a day or two. It will be a fully-functional, accessible, localizable app, with a non-trivial feature set. However, if I write something to ship, it may take a couple of months (or longer). An example is the app I'm writing now. I wrote the "heart" library in about a month and a half. It has a test harness that runs every feature, and the test harness was the largest part of the job. However, the ship app is coming to beta, about a year later. It knocks the test harness into a cocked hat.

ActorNightly 3y ago
There is definitely an aspect of raw time that needs to be put into development to make a prod version of software robust, but that still doesn't account for the bloat. The real issue for the bloat is simple lack of engineering skill. Most "engineers" have very little clue of what goes on under the hood when their code is running, and really only rely on learned patterns to complete their job. So many times I have been given code for a service that when run locally doesn't work, with the explanation that you have to test it in beta stage - the reason this happens is because nobody who started writing that code has any idea of what goes on outside of the boilerplate that is provided for them to fill in.

scifi 3y ago

Have you ever seen a modernist piece of art sell for a bunch of money? There's almost always someone who offers "I could do that". But they cannot. And they will not. It is a statement made to demean others and elevate the self.

geraldwhen 3y ago
Art sales are obvious money laundering. The only way to compete on price would be to have a connection with someone trying to launder money.
- dharmab 3y ago
  Art sales are typically for tax reasons, not money laundering.

Freedom2 3y ago

I'm often reminded of a famous anti-Dropbox comment somewhere, but a lot of the time it's about the right product at the right time with the right marketing.

tqi 3y ago

I think people on both sides of this debate are being obtuse. As we've seen from the rounds and rounds of layoffs over the last 18 months, most big companies were (probably) bigger than they needed to be to function (TBD on X). However it's silly to point to something like Instagram and think "they built something great with 12 ppl, what are all these other thousands of people even doing?" An app used by 1B+ people is more than 10X more complicated than an app that is used by 100M people.

crabmusket 3y ago

> This reminds me of a common fallacy we see in unreliable systems, where people build the happy path with the idea that the happy path is the “real” work, and that error handling can be tacked on later. For reliable systems, error handling is more work than the happy path. The same thing is true for large services -- all of this stuff that people don't think of as “real” work is more work than the core service. This is a fantastic point.

mo_42 3y ago

I guess the simple answer would be: No, first seek to understand. Given this principle, we would mostly realize that even if it was that simple, the business is still years ahead because those people don't just come to work to drink coffee. However, I'd like to point out that there are rare cases when some newcomers can replace existing businesses because they found some technology that simply replaces years of work.

Animats 3y ago

When Cuil [1] did a search engine back in 2008-2010, one of the ex-Google people there told me that the core team that did the Google search engine was under 100 people. It's become more complex since then, of course, but the core search engine isn't using up most of Google's work force. If you did it today, you'd probably want a fairly literal-minded search engine front-ended by a large language model to make it more user-friendly. That might be easier than trying to make the core search engine appear semi-intelligent. [1] https://en.wikipedia.org/wiki/Cuil https://en.wikipedia.org/wiki/Cuil

gardenhedge 3y ago
I remember Cuil.. being awful. How did they launch when it was so bad?
- Animats 3y ago
  Because they were trying to convince the VCs it was going to work. That was unsuccessful; they ran out of funding. The principals were then re-hired by Google.
  - gardenhedge 3y ago
    > The principals were then re-hired by Google. That is shocking!

alexmolas 3y ago

I don't know if "add engineers until the cost of adding an engineer equals the revenue gain plus the cost savings at the margin" is a good idea. A lot of companies did that before/during the pandemic, and after that they had to layoff thousands of people. Under the assumption that your market will always increase it makes sense tho, but that's a huge assumption.

jillesvangurp 3y ago

A lot of hard problems actually become harder with more people. Now you are not only dealing with the problem itself but also with the problem of getting people to agree your solutions are worth the trouble. Cat herding is much harder than innovation. I've built a few products with a skeleton team. You can move really quickly on a lot of issues if you have the right people. And let's face it, a lot of successful companies are not exactly rocket science in terms of what they come up with. Slack: middle of the road chat thingy. Their UX is nice and cute but otherwise there isn't a whole lot of special stuff going on. There are a gazillion alternatives that do more or less the same thing. Airbnb. Cute idea but it's a glorified market place. Twitter has some interesting tech related to scaling search but otherwise it's basically a fast version of mastodon, which is community supported. And they weren't all that fast or scalable initially (fail whale?!). There are a lot of tech companies where the tech is pretty middle of the road. A lot of these companies actually established themselves with much smaller teams than they currently have. My theory is that they actually could not have done it with a bigger team. You need a small and focused team to get results. That's why startups are a thing. Large companies with way more resources struggle to do the same things that small, nimble teams of less than 10 people accomplish. A lot of these big companies established themselves before they bloated their teams; not after. Google was a handful of graduate students that built a nice search engine and ran circles around their competition. They were smart, not big. To move quickly, you need a good team that is not burdened by design by committee style management. Google seems paralyzed lately actually. I'm not sure they'd be able to build another search engine. Plenty of talent and money but their ability to focus all that on anything has gone down the drain.

crvdgc 3y ago

True to a certain extent. Being good at execution is both a blessing and a curse. Nowadays, it's just a matter of time before a product's anti-features catch up with its features. Then only implementing the features would get you ahead.

drt5b7j 3y ago

Found the answer, saved you having to read the whole thing > Businesses should keep adding engineers to work on optimization until the cost of adding an engineer equals the revenue gain plus the cost savings at the margin. This is often many more engineers than people realize. But it's well written, do read it.

Mekulpa 3y ago

People don't scale. It takes a team college a few hours to analyze a bug or to write a new feature or upgrade something for security etc. A week goes by so fast. The last 20% are just what they are.

eviks 3y ago

So how do these arguments help answer whether any criticism of a particular company's size is justified? You could say exactly the same things whether a company employs 10 engineers to tackle no-space-separated Chinese or a 1000

infomiho 3y ago

Off-topic but: body { max-width: 80ch; margin: 2rem auto; font-size: 18px; line-height: 1.5; }

dasil003 3y ago

Whenever these discussions come up, a large contingent of commenters talks about how much headcount a company or product “needs”. But that’s not how growing tech companies are resourced. They hire based on what they can afford, in order to maximize growth. This leads to decreasing efficiency, especially if they don’t have the right technology leadership that knows how scale tech teams, but gives them optionality to chase many new growth directions. As long as the growth continues though, no one is too concerned about efficiency at this stage. It’s only later when the growth slows, that the questions come about how many heads are really needed (and what to do about the unmaintainable state of the systems)

dreamcompiler 3y ago

This article made me think of painting. As in painting the walls of your living room. Looks easy. How hard could it be? Turns out painting is easy if you don't care if it looks like crap when you're done. But if you want it to look good, you'll spend 90% of your time on prep: Moving out or covering the furniture, laying down and securing a tarp on the floor, taking down all the pictures, scrubbing the walls clean, patching holes in the drywall and retexturing, and then carefully masking around the edges of the walls with tape. 90% of the remainder of the time is stirring your paint and carefully painting around all the edges with a trim brush, going extra slow wherever there's a moulding edge that couldn't be masked. There are tricky roller guides that make this faster, but it's still easy to make a mess that requires laborious correction. If you screw up these edges they will ruin the appearance of the room. The next bit of the job is rolling on the big areas of paint in the middle of the wall, which is what everybody sees first. That only takes 5 minutes. Then finally you spend a couple of hours cleaning everything up and replacing the furniture. How hard could it be, indeed.