I think this is a human reaction to their environment. 1. Write code 2. Cleanup the mess 3. Write more code 4. Realise there a better way. 5. Stick with it bec

I think this is a human reaction to their environment. 1. Write code 2. Cleanup the mess 3. Write more code 4. Realise there a better way. 5. Stick with it because effort to change < benefit gained. In Refactoring Kent Beck doesn’t just show extracting variables, functions and classes but also re-inlining them. The problem is at scale, re-inlining is hard. If it were easier to do, it might be done more. I find that waiting for N repetitions of some abstractable code is a heuristic to mediate between the cost and benefit of refactoring. I don’t have an answer for improving it. Perhaps making easier to automatically manipulate the code in this manner? I’ve thought for a while that it would be interesting to treat a code base as a database. Applying documented migrations to it which describe the code transformations occurring (and how to reverse them). Then changing these aspects of code would be trivial. But then your meta program, the set of transformations which generate your current code base, would probably suffer the same problems as your codebase.