The people usually tasked with figuring these things out are new to the team. There can be all kinds of politics and interpersonal baggage with helping the new person with old configuration/ compilation/ deployment stuff.
Often, it'll take one of the legacy leads to step in and clean things up. By then, everyone's annoyed at the new person, and the failure of this effort will get saddled on their back for some time more.
I had this exact issue at a recent gig, and the application architect spent months poking at jenkins to get a clean build. Once he quit in frustration, one of the legacy leads re-engineered the whole thing, in a different language, in a few days.
Legacy lead was one of those "untouchables" in the eyes of the CEO, so there was no influencing him to help earlier, and his reticence cost us a good application architect.
To my mind, this is often a sign of a poisoned, political company culture. The work can be done, but there are non-technical reasons why progress can't be made, even by earnest effort.
Often the non-technical reasons are "management doesn't want to assign the super-lead to the work, but also doesn't want to let the new hire have free reign to rewrite a legacy product. Just fix it."
I've often wondered whether this dynamic is exactly the reason tech culture is ageist. If we hired older developers, the culturally-assumed "gravitas" of age would make their relative social status to more-"senior"-but-younger devs illegible. We might actually have to sometimes give them the right-of-way on making the changes they want to make, even though they're new!
Every company I've worked at for software development has had review / feedback opportunities for my manager. I can't imagine working at a company where feedback from direct reports wasn't a major factor in someone's job performance evaluation.
Then again, I've been very selective in where I work. People like to bash the "culture" stereotype, but it's definitely something I consider when I'm looking for a job... you know, how people are expected to interact with other people, not whether there are ball pits and the like.
The people usually tasked with figuring these things out are new to the team. There can be all kinds of politics and interpersonal baggage with helping the new person with old configuration/ compilation/ deployment stuff.
Often, it'll take one of the legacy leads to step in and clean things up. By then, everyone's annoyed at the new person, and the failure of this effort will get saddled on their back for some time more.
I had this exact issue at a recent gig, and the application architect spent months poking at jenkins to get a clean build. Once he quit in frustration, one of the legacy leads re-engineered the whole thing, in a different language, in a few days.
Legacy lead was one of those "untouchables" in the eyes of the CEO, so there was no influencing him to help earlier, and his reticence cost us a good application architect.
To my mind, this is often a sign of a poisoned, political company culture. The work can be done, but there are non-technical reasons why progress can't be made, even by earnest effort.