6.8.5 Modifiability measures

What this heading covers

Modifiability is measured after the fact, from real changes. Two useful shapes are the effort per change and the proportion of changes that caused a defect. The second is often more persuasive, because it captures the hidden cost of a fragile area. The measure should segment by area, since an average across a healthy codebase and a fragile one hides the area that will cost the next quarter.

Record position: family 30 of 40 in clause 6, under 6.8 Maintainability, which carries 5 families. It is one of the 40 families a programme has to map its measures to, and its elements are listed below. The heading is 6.8.5 in the public contents; the text behind it is not public.

How a measure for this family is built

Divide the effort of the changes in a period by the number of changes, and separately count the changes that led to a defect within a stated window. Report by area or module. Name the change size band, because a large change and a small one are not comparable.

What to put in place before publication

1. Segment by area, not only as a whole-product average.
2. State the window in which a change counts as the cause of a defect.

Evidence to keep

Two questions to ask

• What is the change size band, and what window counts a defect as caused?
• Which area carries the highest change cost?

Where teams usually fall short

• An average change time that hides one module taking most of the effort.

What the number cannot tell you

It cannot tell you whether the change was worth making. It measures the cost of change, not its value.

What happens next

Testability is the last maintainability family and the one that limits how much of the rest can be evidenced.