Rule 29 of 38 · Chapter V — Complexity Has a Cost
Every dependency is a liability
Why this rule exists
Every dependency is code you don't control running inside a system you're responsible for. It brings its own bugs, security holes, breaking changes, and release cadence, and each one is a bet that its maintainers will keep caring as much as you do. The convenience is real and immediate; the liability is quiet and shows up later, usually at the worst time.
In practice
Before adding a package, weigh it against writing the twenty lines yourself. Check its maintenance, transitive dependencies, and how hard it would be to remove. Pin versions, review changelogs before upgrading, and keep third-party APIs behind a thin wrapper so swapping them is local. Periodically audit what you depend on and prune what no longer pays its way.
When it doesn't apply
Don't reimplement cryptography, compression, date handling, or your framework's core. For hard, well-solved problems, a mature, widely-used library is far safer than your own version. The rule is about discipline, not isolationism.