Software has been reused since the days of exchanging decks of punched cards wrapped in listings printed on green bar paper. Packages (that is, libraries) of code are everywhere and are used in an overwhelming number of applications. Starting with a blank screen and writing a major self-contained program is a rarity. Since software reuse is commonplace, the correctness, ability to be understood, security, and robustness of the software package used are paramount. Depending on a package with uncritical trust is dangerous.

Russ Cox shows how one can intelligently and cautiously gain and maintain control of potential problems arising from dependencies on imported software packages. He identifies several considerations in examining a package intended to be incorporated in a project: design (especially the quality of documentation), quality of the code, testing protocols distributed with the package, bug reports and fixes, maintenance, usage, security, licensing, and indirect dependencies to still other packages.

He recommends several measures to gain control of dependencies: testing them alone and in competition with other packages offering the same capabilities, abstracting the dependency to limit the direct invocation of features peculiar to the package (to make substituting other packages easier), isolating the package at runtime, avoiding the dependency by copying code directly (when legal), and anticipating the problems that may arise when packages are upgraded. In short: inspect, analyze, test, and repeat. Trust, but verify.