An ungoverned system decays into a component pile

What it is

When nobody regularly asks “is this a new primitive, or a restyle of one we already have?”, the library grows with page count, not with kinds of jobs. Each addition is locally sane — this card’s radius is two pixels off, that empty state uses a different illustration — and together they become a catalog you cannot search. That process is ungoverned accretion: not one explosion, a string of unblocked reasonable adds. It names the shape of a library after the gate disappears. It is not “who holds the key”, and it is not “the key was so heavy people walked around the building”.

The pile’s test: finding an existing capability takes longer than building another.

Why it happens

Every new name occupies search, documentation, theme adaptation, and defect surface. A caller choosing a component faces a list; as the list lengthens, matching cost rises. When “search and still not sure which one” exceeds “write a good-enough copy in the product repo”, the rational move is to skip the catalog and mint another. If the catalog accepts all comers, that copy goes in too, and the search space grows again. Accretion is a feedback loop: locally justified addition, with no verdict of merge / refuse / demote-to-variant, dilutes the catalog until it stops being information.

Governance here is not etiquette. It pairs addition with subtraction or collapse. Without collapse, component count shadows page count, not duty count.

Where it stops holding

The first month of a product may add fast: joints are still moving, and freezing the catalog early locks a wrong skeleton. The pile test applies after the catalog is treated as a searchable public surface. Campaign microsites and one-shot ops pages may be throwaway sets; they need not run at product-library intensity. Running the main product’s controls the way a campaign runs — append forever, no retirement — yields four buttons, three dialogs, and two tables with no rule for which dies. An open-source showcase catalog that aims to be exhaustive is a sample room, not a live product contract.

Applying it

• Tag every component with call-site count and last-modified date. Zero or one call site, untouched for a quarter, becomes a merge-or-delete candidate, not a recommended default.
• New requests must state “what it replaces / which existing piece it is a variant of / why it is not a parameter on something we have”. If all three are blank, treat it as accretion, not as a primitive.
• Run a quarterly subtraction: collapse duplicates that differ only in decoration; delete names with no callers.
• Check: pick a middling task (date picking, a filter bar, an empty state). Ask an engineer who did not build the library to find “the one to use” on the docs site and start calling it. If they cannot get a unique answer in ten minutes, or they find three names that all look right, the catalog is already a pile. Plot the count of 0–1-call-site entries; a rising curve means accretion is still on.

Related

• Same group: R1.06.1 Who may add a component must be named · R1.06.3 High contribution cost drives teams around the system · R1.06.4 Promote only after several real call sites exist · R1.06.5 Review the public API, not the implementation internals · R1.06.6 Maintenance is accepted with the component, not after the merge
• Adjacent: R1.02 Component libraries and variants · R1.18 Adoption and compliance metrics
• Search terms: ungoverned accretion · component pile · catalog entropy