When To Roll Your Own X

When should you reuse code and modify it to your requirements? When should you roll your own? There's no general answer to this question, but a few guidelines that I've picked up over the years.

• Don't roll your own crypto (unless you're an expert in cryptography, xkcd)

• Don't use the code if your usage of the library is in a gray area of (or worse, not allowed by) the code's license.

• "If it's a core business function – do it yourself, no matter what." – Joel Spolsky, In Defense of Not-Invented-Here Syndrome.

• Do you need to fork the library? Do you need to monkey patch something private? Maintaining even simple patches or modifications to upstream libraries takes significant effort (which scales with the activity and maturity of the underlying dependency).

• Sometimes a little copying is better than a little dependency.

• What's the overlap with your use case? Great libraries can sometimes be used for wildly different use cases that the authors didn't intend, but good libraries buckle outside the happy paths. Even if you're using it for the intended purpose, you might only need a small, self-contained part (most modern package managers and bundlers can tree-shake unnecessary dependencies away.

• If the library is end-of-life, find an alternative or write your own.

• The cost of maintenance. Your library will need documentation and bug fixes. You will need to onboard new developers. The corollary to Joel's point on NIH Syndrom is innovation tokens – pick your core competencies wisely.  

• Are contributions welcome? Is there a path for feature requests? Depending on the extent of your integrations and extension, you might want to find an alternative or write your own if you can't contribute back.

• The time value of money – are you in a stage where you're prototyping? Maintaining a critical legacy system?