Libraries, perfect pre-fab building blocks or dangerous explosives?


Since library code is mostly not visual, let me tell you a little story first.

Let’s compare software to a brick wall. To build one you need bricks and some glue to keep them together. If you had to make the bricks yourself, it would take you ages to complete your wall. So every sane mind will buy his bricks to speed up the build process of building the wall dramatically, which is a very good thing. But if you can’t find bricks in the color you like, or they are not strong enough to support the weight of your building, the wall will collapse! Quickly check each brick before you glue it, because it is a mess if you need to get it out of your wall and worst case you wall will simply collapse. Pieces of pre-glued wall: a dream coming true when it comes to speed… at least when they used the same bricks and same glue and did check the quality of their bricks themselves! When you want to combine the walls into a fully functional house, and add more floors or maybe you’re building a skyscraper, keep in mind that the building is only as strong as the weakest part. If your building keeps growing you’ll probably reach the point where the bricks you used are not strong enough to support the building anymore you don’t just build another wall around it, but try to enforce the foundation first. If that is not possible, start searching another building for your project!

How that translates into software and libraries?

  • Always check the issue tracker of the project (are there a lot or are there important issues that are never fixed?), last commit date and rating when possible. Actively maintained projects usually get better over time, even when there are a lot of issues at initial stage!
  • Check if the library does not include a lot of other libraries. If all it does is using other libraries, then you’re better off coding it yourself in most cases since you can ditch stuff you don’t really need.
  • Verify that the library 100% solves your problem, and preferably is future proof.
  • When in doubt, dive into the source code to assure the library works as explained and expected, and check possible edge cases that occur in your project.

Leave a Reply

Your email address will not be published. Required fields are marked *