Common misunderstandings about large software companies

I did not expect to see big-company apologia on Hacker News.

https://en.wikipedia.org/wiki/Apologia

The thing this (very good) post doesn't mention is that big companies select for blub languages because that's where the most low-cost labor is, in that you can hire multiple Java developers for the cost of one Haskell developer, even if Haskell might be objectively a better choice for the project.

I liked this post. I may have some minor qualms (e.g. while I think execs should be proxies for the customer, they have many other competing motivations that can push customer needs way down), but I especially liked the closing section:

> Understanding before criticizing

> Large software companies have real problems. Some are structural. Some are cultural. Many are self-inflicted. But many of the behaviors people complain about are not pathologies – they are consequences.

> If you want to criticize how large organizations operate, it helps to first understand why they operate that way. Without that understanding, the criticism may feel sharp, but it will not be useful.

I see that kind of "criticizing before understanding" all the time on HN, and while that's probably just inherent to an open forum, commenters who do that should realize it makes them come across as "less than insightful", to put it generously. Like I see tons of comments often about how managers only get to their position through obsequious political plots. And sure, that may exist in some orgs. But you can always tell when folks have never even considered the competing forces that act on managers (i.e not just the folks they directly manage, but requirements coming from higher ups, and peer teams, and somehow being responsible for a ton when you actually have few direct levers to push) and solely view things through the lens of someone being managed.

Equating process to risk aversion is a mistake I hadn't seen before. It's true that moving slow makes it less likely to make something worse per unit time, but it also makes it less likely that anything will get better. It means that you don't try many things, and can't get important things done quickly.

You can ensure quality by making features opt-in, having a beta program available to risk tolerant users, adding QA resources, having representative users in captivity (employed at the company).

There is no law that says that you must move slow or do less in order to be low risk, you can also do a lot, move fast, and only let the best out.

   Coordination is almost free in a ten-person startup. It is still relatively easy in a forty-person company. 

I find coordination difficult even for two / three persons for any given topic where there the tree of dependencies (of sub tasks or others topics related to it) isn’t trivial and there are unknowns to research. Unless those persons are doing the same thing and are constantly communicating, which is very expensive

There was a post, I think on the Uber engineering blog, that stuck with me. It essentially boiled down to: it's easier to change the tech stack than the hiring pool, and talked about deliberately setting something up that was technically less optimal but easier to hire for

Corollary: it's perhaps easier to throw money at fancier hardware to improve performance, than the alternatives