Why Dependency Management Matters and How to Do It Right

"Directly using a dependency found on the Internet is like hiring a developer you know nothing about," the article opens, emphasizing the hidden risks of blindly adding external packages.

During a four‑hour Mob Code Review (Mob CR) of a 1,000‑line Go project, the team discovered many duplicated and unstable dependencies in go.sum , prompting a refactor that dramatically reduced the dependency count.

Dependency management is presented as a crucial checkpoint in code review because modern software relies heavily on open‑source libraries, many of which lack rigorous testing, security guarantees, or long‑term support.

Why Dependency Management Is Important

Open‑source libraries accelerate development but also introduce security vulnerabilities (e.g., Log4j in 2021) and quality concerns. Even well‑maintained projects from large vendors can have unresolved issues, making dependency risk a serious challenge for commercial organizations.

The article stresses that ignoring these risks can lead to costly failures, especially in production environments where downtime or data breaches can threaten a company's survival.

What Is Dependency Management

A dependency is any external code your application calls. Using packages avoids reinventing common functionality such as logging, compression, or date handling.

Historically, developers manually downloaded and built libraries like PCRE, Boost, or JodaTime. Package managers now automate this process, allowing even tiny utilities—like the eight‑line escape-string-regexp npm package—to be published and reused.

var matchOperatorsRe = /[|\{}()[\]^$+*?.]/g;

module.exports = function (str) {
    if (typeof str !== 'string') {
        throw new TypeError('Expected a string');
    }
    return str.replace(matchOperatorsRe, '\\$&');
};

Today every major language has a package manager (npm, Maven, NuGet, Packagist, PyPI, RubyGems) offering hundreds of thousands of reusable modules.

Where Problems Can Occur

Using an unknown package means your program inherits the unknown author’s design, testing, and maintenance practices. If a vulnerability or defect appears, you may have no recourse beyond fixing it yourself.

Commercial software historically relied on trusted, paid components; open‑source distribution has shifted trust to reputation and community adoption, which can be misleading.

Risks are quantified as the sum of potential negative outcomes weighted by their probabilities, and the cost of a failure in a production system can be extremely high.

Using Dependency Packages: Precautions

Before adopting a package, treat it like a new hire: verify its design, code quality, test coverage, maintenance activity, popularity, security record, license, and its own dependencies.

When issues are minor, consider fixing them or contributing a patch; for serious problems, replace the package or implement the functionality yourself.

Open‑source authors provide useful code but no guarantee of quality or support, so developers must be prepared to audit, test, and possibly refactor the dependencies they rely on.

The article concludes with two main checklists:

How to Choose a Dependency Design considerations Code quality Automated testing Debugging and maintenance Adoption rate Security License compliance Transitive dependencies

How to Use a Dependency Validate through your own tests Encapsulate the external code Isolate the dependency Avoid unnecessary dependencies Define an update strategy Monitor for new issues Periodically reassess its continued use

Further detailed discussion of each point will appear in the next articles.

References:

Rachel Potvin and Josh Levenberg, “Why Google Stores Billions of Lines of Code in a Single Repository,” Communications of the ACM 59(7) (July 2016).

Russ Cox, “Go & Versioning,” February 2018.

Ken Thompson, “Reflections on Trusting Trust,” Communications of the ACM 27(8) (August 1984).

GNU Project, “GNU General Public License, version 1,” February 1989.