A colleague argues that the Common Reuse Principle doesn't matter because "unused classes in a dependency cost nothing — we never call them." What concrete costs would you cite to rebut this?

## Restating the disagreement precisely The colleague's model is: *dependency = the set of code I execute*. The correct model is: *dependency = coupling to another component's release cycle and dependency closure*. Once you accept the second model, every item below follows mechanically. ## 1. Release coupling (the original motivation) Martin's motivating scenario: component **B** contains classes you use and classes you don't. B releases version 3.1 because of a change in the part you never touch. You now face a forced choice: - **Upgrade:** rebuild, re-run the test suite, possibly re-run integration/e2e, possibly re-certify (in regulated environments: re-validate, re-file), and redeploy. Non-zero engineering time for zero functional benefit. - **Don't upgrade:** pin to 3.0 and start accruing drift. The next security patch will be published on 3.2, on top of the changes you avoided, so you pay the deferred cost with interest — and meanwhile other components in your graph may already demand 3.1+. Neither option is free. This is the cost CRP is designed to eliminate: a consumer should only be exposed to releases of things it actually uses. ## 2. Transitive dependency closure The unused half brings its own dependencies. A component you took for a string helper may drag in an XML parser, a template engine, a reflection utility, a metrics client. Effects: larger download, larger lockfile, more supply-chain surface, more license obligations to review, more entries your SBOM (software bill of materials) must list. ## 3. Version-conflict / diamond surface Every extra transitive is another node that can conflict. Two of your components want incompatible versions of a library that neither of you asked for — a library that only exists in your tree because of classes you never call. In ecosystems with a single flat resolution (Java classpath, Go modules, Python site-packages) this can be genuinely unresolvable; in ecosystems allowing multiple copies (npm), it inflates size and can break identity checks across duplicate copies. ## 4. Security, licensing and compliance A vulnerability scanner reports on what is *present*, not on what is *reachable* (reachability analysis exists but is neither universal nor fully trusted). So a CVE in the unused subsystem becomes your ticket, your SLA clock, your upgrade. Similarly a copyleft or restricted license in a transitive of the unused half becomes your legal review. ## 5. Build-time and runtime weight More code to fetch, verify, compile against and package. Bigger container images and slower pulls. Bigger client bundles (in browsers, directly user-visible latency). More classes to load and verify at startup, which matters for serverless/short-lived processes. Slower IDE indexing. ## 6. Human/API surface Every consumer's autocomplete, documentation and mental model now contain irrelevant concepts. New engineers cannot tell which parts of the component are "for them". Grab-bag components also attract more junk over time (broken-windows effect), which compounds every cost above. ## 7. Coupling to the wrong team's cadence Organisationally, depending on a component means depending on its owning team's release discipline, deprecation policy and support level — for the whole artifact, not the slice you use. ## The honest counter-arguments (know these too) A good candidate acknowledges when the colleague is *partly* right: - **Internal monorepo, one build, one deploy unit:** if consumers and provider are built and released atomically from one repository, release coupling largely disappears and only build-time and cognitive costs remain. CRP pressure is genuinely lower there. - **Dead-code elimination / tree shaking:** in some ecosystems the *shipped bytes* of unused code can be removed, addressing cost 5 — but not costs 1–4, and not when reflection or dynamic loading defeats the analysis. - **Splitting is not free:** more artifacts mean more versioning and release coordination. The rebuttal is not "always split"; it is "the cost is real, so weigh it deliberately." ## How to make the argument stick Use evidence, not principle: show the last N releases of the component and how many were irrelevant to your service; show the transitive tree contributed only by the unused half; show the open CVEs in that subtree. That converts an abstract principle into a number.