Volatility measures how often two software concepts change together, including how frequently they could need to change as product strategy evolves. It helps distinguish tolerable dependencies from costly coupling. section 9.2.3 section 12.1
Assess volatility by asking:
- How frequently have the concepts changed together historically? section 9.2.3
- Could a change in product direction make them co-change more often? section 9.2.3 section 12.1
- Are current constraints, such as legacy code, hiding a higher desired volatility? section 9.2.3
Low historical volatility, changing strategy
Two concepts that change together only once per year create relatively little coupling pain, even when their coupling is intrusive. A new innovation strategy could make them co-change frequently, increasing the value of separating them. section 9.2.3 section 12.1
Volatility is one factor in the coupling model Pain = Strength × Volatility × Distance. Low volatility can keep coupling costs low, while changing strategy can make the same dependency more expensive. section 9.2.3 section 12.1
