I have been thinking about how how gradual modularization fits into work of...

I have been thinking about how how gradual modularization fits into work of "changing code for the future" (trying to avoid all of the words in the chart)...

Does this resonate? What questions do you have?

@mehulkar Let's start in the bottom right (refactoring): I have discussed TDD's cycle of red-green-refactor and specifically the question of "how much refactoring is ok in the context of the feature work." Whatever you come to, I believe it falls short of providing the answer as to how to decide on large scale codebase evolution.

@mehulkar When it comes to this kind of large scale work, the most often proposed solution I come across is the strangler fig pattern: Build the new thing separately until you have the functionality (or parts thereof) that you can move consumers over to the new implementation.

This chart attempts to show that in the move from small to large we thus also tend to switch approaches: from evolution (right side) to replacement (left side).

There are alternatives.

@mehulkar

Reimplementing (bottom left) I have sometimes seen proposed as a practice. Implement a class and tests, then delete the class and write it again, implementing all the tests.

Gradual Modularization (top right) uses large scale system modularization feedback (in the form of structure rules and their violations) to allow for a refactoring of the entire system to become feasible.