Package Management

We all use software written by other people. Whether it is libraries that we statically link, like in the old days of C, packages we import, like in most modern frameworks, or even external microservices, no developer stands alone. While often shown as a solitary, isolating job in the old “hacker” type movies, software development has since become an environment requiring lots of collaboration. This collaboration still occurs, even if you don’t know (or communicate with) the person whose code you are relying upon. While this collaboration has allowed us to build wonderful things, it also comes with a price. As a friend describes it, hell is … other people’s code. You might be able to trust someone else’s code and you might not, but you can never trust the notion that someone else’s code is trustworthy for any given purpose. There are lots of issues with bringing in dependencies to a codebase. The code might create security issues, performance problems, break your app in subtle and hard-to-detect ways, or even trap you in an ancient version of your framework of choice. While it may be cheaper and easier to import a software package to help with whatever you are doing, adding a dependency is not a completely free operation – it requires maintenance and verification of the code you are bringing in. At the very least, even if the current version is perfect (unlikely), subsequent versions might still cause problems. In essence, as in economics, there is no free lunch. Anything you do has a cost, and that includes the act of bringing in third party code to avoid having to do certain work yourself. If you are going to use third party code (and you certainly are if you are going to get anything done), then you need to make sure that your development processes take the unique risk and opportunities into account that such code provides. Done properly, these practices will not only insulate you from a lot of the risk of using other people’s code in your applications, but can also improve the overall quality of your code base. Using third party code improves productivity and is often necessary in order to get things done in modern software development. However, doing so is not a zero cost act. Third party code can and will cause you problems in your development, testing, and production environments alike. These problems can range from small annoyances to system failures, to security holes (and intentionally introduced vulnerabilities) that can utterly destroy the quality of your system. If you are going to use third party code, you MUST take steps to make your implementation as stable and safe as possible, while still allowing you to update at a reasonable cadence. It takes practice and discipline to do this properly, but you need to do it. Episode Breakdown Be able to detect out of date packages While your package manager will likely tell you that one or more packages are out of date, it’s unwise to trust your team to update packages as part of their normal course of work. It balloons the testing scope, takes time, and is easily missed. This probably means that you will want some sort of alerting that lets you know when packages are out of date, possibly even stopping builds and deployments if something is out of date “enough”. Be aware that not all packages need to be updated immediately, and that people may not necessarily install the latest version immediately. You’ll need to stay on top of this to avoid ending up with wildly out of date packages being used by your codebase. You should also be aware that some package updates change things like licensing, interfaces and the like. You may not be able to upgrade immediately (or ever). This means that you’ll need to track the status of the various packages you are using. Make sure you are on the mailing and notification lists f...