I think the graphs, bu fault of 'value' not being defined, are showing a hybrid of the long-term and immediate value of the code. Take, for example, a strict r

I think the graphs, bu fault of 'value' not being defined, are showing a hybrid of the long-term and immediate value of the code. Take, for example, a strict refactoring of the code, in the sense that only implementation is being changed and no features are being added. The immediate business value of that action is near zero, but the long term value is more. What the graphs point out is that, due to manual testing and production environments rigorously stress-testing a particular, perhaps brittle, snapshot of the code, the amount of refactoring and beautification of the codebase required to provide a baseline level of long-term value equivalent to the spike is much higher. Yes, the code will be cleaner, and easier to maintain and update for the future, and the resulting spikes from testing and production deployment will be that much higher, too. Take a look at the very last graph. I would posit that once the code is beautified and a more flexible version deployed, non-source readers would see another spike at the end, but from the original spike, it's hard to justify the valley of little incremental value.