202107291950 Optimizing rate of change between requirements and implementation

There's a saying that says

A small change in requirements should only result in correspondingly small change in implementation.

I believe this is false or — perhaps more precisely — misleading

If we describe the act of implementing requirements as a function $f(reqs)=\mathrm{implementation}$, then the key thing to remember is that we know nothing about how this function works and therefore it's our job as developers to choose the characteristics of $f$. We have control over whether we should minimize its rate of change (its derivative $\frac{\delta i}{\delta r}$) or whether we should minimize or maximize understandability, maintenance, simplicity or any other number of characteristics of $f$.

A correlated concept is the 202110111901 Run to change ratio of a program. This note is about the optimization of that change rate, and the other one uses this change rate to build a meaningful metric about the value in making changes relative to its frequency of use.