…I used to like building polyhedron models out of card. Here is a photo of me, probably around 1987ish, spray-painting a compound of ten tetrahedra. Evidently the photographer had partially obscured the aperture with their finger, but there were no digital cameras back in those days, you only found out your mistakes when you had the picture developed!
The artist at work
Making a model out of card was a long and laborious process. First, armed with a protractor and ruler, one had to draw the net on card, making sure there were tabs in the right place to glue the thing together. Then it had to be cut out, and the intended folds scored very carefully with a craft knife (you need them to fold cleanly, but if you cut through the card you’ll have to start again). Finally, it had to be glued together to give it three-dimensional form, a process which got increasingly fiddly as access to the interior became harder.
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.
