Early on, companies would tend to take version control like SCCS, and layer their own SCM systems atop it, to address some of the most obvious team project pain

Early on, companies would tend to take version control like SCCS, and layer their own SCM systems atop it, to address some of the most obvious team project pain points. The bespoke layers I saw were usually kludgey, but sometimes they worked well enough, in a "worse is better" kind of way. Other times, people were greatly relieved to eventually get a better off-the-shelf SCM system. This building atop SCCS is an example of starting with the minimum and adding what you need. It has different pros&cons, compared to a more typical contemporary approach of starting with the maximum off-the-shelf framework/platform/service, and figuring out how to get it to do the simple thing you actually need. There's a sweet spot in between the two, of sometimes using some big/medium-complexity off-the-shelf thing, and other times keeping it simpler, while making better decisions than flipping a coin. Though that tends to get lost in the reality of resume-driven-development, when the incentive of a decision-influencer to add a keyword to resume isn't aligned with the goals of the current project or current company. (But companies only have themselves to blame for this, when they hire by the keyword. Of course, selecting for and rewarding pursuit of keywords, that's what they'll get. Similar with hiring for Leetcode.)