How is that even possible?

Wasn't CI invented to solve just this problem?

▲ vlovich123 5 days ago | parent [-]

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 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.

Your choice: do you have the most senior engineers spend time sporadically maintaining the build system, perhaps declaring fires to try to pay off tech debt, or hire someone full time, perhaps cheaper and with better expertise, dedicated to the task instead?

CI is an orthogonal problem but that too requires maintenance - do you maintain it ad-hoc or make it the official responsibility for someone to keep maintained and flexible for the team’s needs?

I think you think I’m saying the task is keeping the build green whereas I’m saying someone has to keep the system that’s keeping the build green going and functional.

▲ AdieuToLogic 5 days ago | parent | next [-]

> 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." It would make sense if, instead, the description was "application", "product", or "system."

Many software engineers use and interpret the phrase "build system" to be something akin to make[0] or similar solution used to produce executable artifacts from source code assets.

0 - https://man.freebsd.org/cgi/man.cgi?query=make&apropos=0&sek...

▲ vlovich123 5 days ago | parent [-]

I can only relate to you what I’ve observed. Engineers were hired to rewrite the Make-based system into Bazel and maintain it for single executable distributed to the edge. I’ve also observed this for embedded applications and other stuff.

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.

	▲	AdieuToLogic 3 days ago \| parent [-]
		>>> 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

▲ wojciii 2 days ago | parent | prev [-]

I worked in companies that did this .. 20 years ago. I didn't imagine that this was still possible.

For me it's just about rules/discipline: Commit working code with passing unottests. Everyone is responsible for fixing stuff. You break something you'll fix it.