It seems common for products or product lines to evolve into a collection of components, technologies, processes, etc. When components come from different companies or teams, it’s likely each has a unique dev culture. So what? As time marches on, a lot of change will occur, regardless of ones desire for the status quo.
Let’s take the position of adapting new components as they are. Depending on the size, the component may come with a build system that includes a differs source control system than what is normally used. The path of least resistance is to adapt the new process as is. The team now has 2 processes & 2 source control systems…
Before you know it, team members move on; now the new folks are left re-building 2 mental models, processes, etc, assuming only one misfit component was added to the team.
Consider adding a small component of an odd language, say Visual Basic, into a C++ shop. Again, it seems efficient to absorb the original technology and it is. Until we get to our favorite, inconvenient team truth: turn-over. Developers end up supporting a larger number of technologies, but it’s likely their depth of knowledge is shallow. The “guru’s” who know everything may be blocked from moving on in the organization and the business is similarly hamstrung by irreplaceable resources.
A mature development shop will recognize the value of simplicity, which brings consistency across the board: work item delivery, build processes, testing environments, development time, estimates, security practices, code reviews, deployment, etc. Also, such a shop will understand the cost of “re-writing” as a part of the original cost.
The team will either re-factor the component to regain their speed or choose to lose performance.