In software engineering we store our code in GitHub repositories that provide utilities to manage version-controlled text. These repositories act as the host for logic for business operations that benefit from software. It is relatively easy to track history of how code has evolved and lock down who you should to ask about a particular part of code.
In software, we have this unfortunate habit of letting organizational proclivities get in the way of sustainability. Many teams insist on operating with their own level of secrecy, ownership rights, and their own standards for what code is allowed to be brought into the codebase.
This pattern leads to siloes that beget massive inefficiencies. Oftentimes, I have seen repositories that are set up with the same exact skeleton. They use the same framework, same Dockerfiles, the same env variables, analogous deployment config, and myriad shared packages. Any time a bug is found in one of the siloed repositories, there exists the unavoidable possibility that this bug never gets shared between repositories. I’m willing to bet that the slowdown is non-linear as a function of how many times you split up your code. This is also true for the magnitude of your operational risks. Management and competent employees work as a buffer to this inefficiency by being able to juggle different complex codebases and recognize opportunities to share efficiencies. As a senior leader, you should be aware of how egregiously you’re wasting the time and aptitude of your employees. By consolidating work, you allow your devs to focus on providing value to the company and focus on thoughtful product improvements. Oftentimes we spend a massive amount of times acting as code plumbers, fixing leaks and pre-empting risky scenarios.
This title is clickbait — The phrase “Monorepos” was a mistake, but not because monorepos themselves are bad. I think it was a mistake in branding, calling something a monorepo implies its something different and singular. Instead I think we should be calling them “multi-target/multi-package repositories”