At the only job I've had where Bazel was in use, we had a team of 4-5 engineers dedicated to maintaining Bazel for a larger team of about 25.
Bazel is a nightmare. I wouldn't wish it on my worst enemy.
Bazel is a nightmare. I wouldn't wish it on my worst enemy.
Don't look at headcount to gauge complexity, difficulty, etc.
What I've experienced is the larger the team the more likely to have dilution of ownership. The less ownership the less likely each person will spend the energy or fully understand solving root causes.
In two ways, one being that more people legit need a more complicated system. You want that so that they interact with the system, not with each other.
The other being a bit of a Parkinson's Law. That is specifically that you will expand work to fit the allocated time; but I posit that you will also expand work to fit the people doing it. So, more people pushing ideas into the codebase will keep more ideas in the codebase. Even if fewer would work.
What parts of Bazel were a nightmare? What problems were fixed by these 4-5 people that were previously impacting all 25 people routinely?