1. It's really hard to tell if any of the people writing blog posts about these things have ever experienced the larger scale monorepos or not for any length of

1. It's really hard to tell if any of the people writing blog posts about these things have ever experienced the larger scale monorepos or not for any length of time. As best I can tell, the answer is "no", and they are mostly writing based on perception. They don't appear to even do things like "try to talk to people who have experienced the good and bad of it". While the writing is fun, it makes it a lot less useful in both directions, IMHO. 2. The author is right that planning more than 6 months for smaller scale companies makes no sense. However, both of these authors seem to fundamentally miss the actual problem in large companies, which they assume is around engineering and scaling large systems. In fact, it is not. The underlying issue is that engineering a thing is no longer your main cost. This is one of many reasons larger teams/companies are fundamentally different (as this author does correctly point out). There are 2080 work hours in a year. If i have 8000 developers, and I have to spend an hour teaching them a new thing, i just spent ~4 people for a year. If you spend a day teaching them something new, I just spent ~31 people for a year. If you spend a work week teaching them something new, I just spent ~154 people for a year. That's just the basic learning costs, it doesn't include migration costs for code base or anything else[1]. But these costs certainly dominate the cost to engineer a solution as you get larger - the systems being talked about here (which have scaled engineering wise) are not 50 people a year (i work next to them :P). Not even close. In some sense, talking about the engineering challenges makes no sense - they basically don't matter to the overall cost at large scale. These same things apply to most of the broader (in the sense of who it touches) pieces of developer infrastructure like programming languages, etc. As you can also imagine, you can't stand still, and so you will pay costs here, and need to be able to amortize these costs over the longer term. In turn, this means you have to plan much longer term, because you want to pay these costs over a 5-10 year scale, not a 1 year scale. [1] It also excludes the net benefits, but you still pay the costs in actual time even if you get the benefits in actual time as well :) Also, productivity benefits from new developer infrastructure are wildly overestimated in practice. Studies I've seen basically show people perceive a lot of benefit that either doesn't pan out or doesn't translate into real time saved. So at best you may get happiness, which while great, doesn't pay down your cost here ;)