I can guarantee that there was a huge thread about this in the bug, and it was not as simple as "nah don't ship it". There are many technical reasons/tradeoffs involved, and sometimes perfectly reasonable improvements are not possible. That's at every software org.
It's odd, and not what I heard much about FAANG say 5 years ago, but it is what it is.
Among root causes:
- people hate tattletales
- everyone is overworked.
- no second-level manager has enough time or upside to run an investigation every time a first-level manager says "no they forgot about {concurrency|tps report v2.1|memory use}" and another first-level manager, not responsible for the code, says its fine.
- hell, your first-level manager doesn't have upside because it's just conflict. If you got someone knocking around for you, you got a good one.
EDIT: Here's a thread with similar tales. https://news.ycombinator.com/item?id=36853039
Speeding up X isn’t on their roadmap/plan.
Even though someone did the work, even with full tests/etc, integrating it will steal time from the testers. Even if it’s only 2h.
That means they might not hit the existing plan, even if it’s a 0.5% chance. So they won’t take the risk. After all, it’s not part of the plan.
So it goes on the backlog for when the roadmap is smaller than capacity (read: never). Because no one is going to push hard enough. That would waste capital needed to get the Blorp team to do the thing needed to complete stuff on your committed roadmap on time so you don’t get screwed and left holding the ball.
And all that is when operating in good faith, assuming the receiving team isn’t pulling NIH or some other nonsense.
Really? Cause only one of us saw this whole thing through from start to end…
It boiled down to “stay in your lane, chromeOS team”.