Change-proneness

What it means

Change-proneness measures how often a file, module, or service changes. Frequent change can indicate active product development, unstable requirements, coupling, or a valuable boundary that receives investment. The signal becomes more useful when paired with change size, authorship, and defect outcomes.

Example

A configuration module changes in nearly every release because multiple teams add options. The team examines whether a stable extension point or ownership boundary could reduce coordination without slowing legitimate evolution.

Limitations

High change frequency is not inherently technical debt. A successful feature may change often, while quiet code may be risky but untouched. Track the period, change type, and excluded generated files.

How to use the signal

A component that changes often may be valuable product code, so combine this signal with defects and ownership before calling it debt.

Separate feature evolution, generated updates, and maintenance edits so frequent change is interpreted in its actual context.

Weave can help segment change-prone components by review time, rework, and delivery signals. Use version-control history for the measure and Weave for the surrounding workflow interpretation.