>>> You have a team of 20 engineers on a project you want to maintain velocity on. With that many coooks, you have patches on top of patches of your build system ...
>> The scenario you are describing does not make sense for the commonly accepted industry definition of "build system."
> I’m not sure why you’re dismissing it as something else without knowing any of the details or presuming I don’t know what I’m talking about.
My apologies for what I wrote giving the impression of being dismissive or implying an assessment of your knowledge. This was not my intent and instead was my expression of incredulity for a build definition requiring 20 engineers to maintain. Perhaps I misinterpreted the "cooks" responsible for build definition maintenance as being all of those 20 engineers. If so, I hope you can see how someone not involved in your project could reach this conclusion based on the quote above.
Still and all, if this[0] is the Bazel build tool you reference and its use is such that:
With that many coooks[sic], you have patches on top of patches
of your build system where everyone does the bare minimum
to meet the near term task only and it devolves into a mess
no one wants to touch over enough time.
Then the questions I would ask of the project members/stakeholders are:
1 - Does using Bazel reduce build definition
maintenance verses other build tools such as
Make/CMake/etc.?
2 - Does the engineering team value reproducible build
definitions as much as production and test source
artifacts?
3 - If not, why not?
EDIT:
To clarify the rationale behind questions #2 and #3:
Build definitions are production code, because if the system cannot be built, then it cannot be released.
Test suites are production code, because if tests fail, then the build should fail and the system cannot be released.
0 - https://bazel.build/start/cpp
