This is the 6th part of a series about 67 Bricks’s coding principles. The previous posts are: 1, 2, 3, 4 and 5.
The principle
Where reasonable, lean on reputable, existing libraries rather than writing your own solution for a problem that has already been solved.
There are a number of well known edicts in software engineering that relate to this principle. “Reinventing the wheel” describes writing your own software to solve a problem that has already been solved adequately. “Not Invented Here” (NIH) syndrome describes a tendency to believe that only self-authored code is valid and therefore to avoid using any third party software or libraries.
I’ve certainly been guilty of reinventing the wheel – sometimes because of NIH syndrome and sometimes because it didn’t occur to me to check whether the wheel had already been invented. I don’t think I’m alone in this.
At 67 Bricks, we encourage the use of libraries and third party software in our solutions because we recognise that our real goal is to create valuable products for our customers. And we can do that more effectively when we lean on existing solutions to solved problems.
It’s worth considering that the authors of a library are likely to have dedicated considerable time to their solution and to have encountered and fixed problems you haven’t thought of yet. Problems, big and small – from dropdown components to search engines – have endless complexities and edge cases. If we tie ourselves up on these details, we are not working on solving the real problem of the system we’re working on.
Jeff Bezos said a company should “focus on what makes your beer taste better” as an analogy to explain why a software company might use AWS rather than managing servers etc in house. This is a useful way to look at writing software. What makes our “beer taste better” is understanding our customers’ problems and designing systems and products that solve them. We are not directly making our “beer taste better” if we’re spending time reimplementing an HTTP server or a frontend component library.
However, it’s important to evaluate libraries before relying on them. Consider questions like how actively is it developed and maintained? Is it compatible with other tools in use? Does it have issues or bugs that might make it difficult to work with or cause problems for the larger project? Is its license compatible with the project? Is it accessible? Your colleagues and the community will have thoughts, recommendations and advice, so don’t be afraid to ask.
The infamous leftpad incident highlighted the inevitable vulnerability that comes with relying on 3rd party libraries. The specific issues with NPM that allowed that to be such a problem have since been addressed, but nevertheless it’s worth bearing this warning in mind when bringing in any dependency. We always want to make sensible choices about when to rely on a library and when not to. There’s a balance to find here – sometimes it weighs in favour of choosing the library despite that vulnerability and sometimes it doesn’t.
As with so many decisions, it comes down to a cost benefit analysis. But it’s important to be realistic about all the costs. There are potential costs of using a library: it may be badly supported or become deprecated, it may have or develop a security hole – or worse, have a security hole put in it maliciously. But there are potential costs of not using a library too, primarily time. Can you afford to spend hours, days or weeks implementing and then maintaining some piece of your system that has already been implemented – perhaps better – already?
So I would advise using libraries liberally where they add value and allow you to concentrate on solving more valuable problems, but remember to evaluate them adequately. Ultimately aim to find a balance between not reinventing the wheel while also not bringing in a new library for every little problem you find however small.