Writing every line of code myself instead of pulling in dependencies satisfies my deep personal desire to build everything myself and think that I’m the best coder in the world. It reinforces my belief that I’m building something new and special and unique to this particular project or customer. And it helps cement my position as the person who cannot get hit by a bus or fired. The less readable my code is, the more necessary I am to the organization.

Your programmer is going to quit

When an organization evaluates to what degree they should incorporate open-source dependencies into their next project, it is easy to fear software floating around the internet written by people you’ve never met. Your own employees are very real, and human, and nearby. They seem somehow permanent, even though average employee tenure in the IT sector is extraordinarily low. At Google, for example, which pays $107k salary on average with its legendary perks, only 50% of its employees stay for more than one year. Losing key employees and their knowledge is an inherent liability in hiring high-value workers; continuing the project of a programmer who no longer exists is extremely hard, regardless of how smart you are. Relying on any single vendor or employee carries plenty of risks. In the context of this reality, relying on hundreds of people all over the world to share in the construction and maintenance of an important software tool might seem somewhat less risky.

Re-inventing the Wheel is Expensive

I love programming. The only thing I love more than programming is not programming. I realize that almost everything I’m going to do exists already in some form; I’ll probably be more productive by taking the work of someone else and building on it, and relying on the collective experience of the other users to help vet the tool, grind out the serious bugs, and collaborate to resolve questions and issues. I get to leverage Adam Smith-style labor specialization, where people who have more in-depth domain-specific expertise have already built something better. The alternative is

Old School

The mindset that everything should be built in house is old-school. Even if you don’t agree that there must exist a provably optimal way to build software, it’s not hard to see that trying to build things in-house that already exist – also called re-inventing the wheel – is going to cost you more time and money than is necessary. Consider whether it’s more effective to depend on and contribute to software that’s already supported or trying to cultivate and pay for an in-house employee or a team to build some novel, probably inferior thing. The business will have to bear the costs of QA and maintenance forever, but the employees who signed up for this responsibility will be long gone. And they know it.