It's focus is not on constant refactoring but constant rewriting. Turns out easily rewritable code means easily deletable code. I think the major drawback of this approach is it's hard to follow for systems where you don't yet have some kind of intuitive sense of how the low level implementation requirements since you end up leaving those for last.
makes sense. i guess in my limited experience trying to unit test existing code that's a gnarly mess, as you gradually rewrite it to decouple dependencies and isolate accreted responsibilities into single-purpose collaborator objects that can be dependency injected, and generally get rid of as much global mutable state as possible and replace things with genuine functions, you end up with something that's broken into components that can be easily constructed and tested in isolation. i can understand then how it would be easy to delete some of those components. (not saying your approach is exactly the same as what i am describing here).
re: the link
> While code reuse has been commonly promoted as a universal good over most of the history of computer science, it comes at an increased cost of change & replacement. In order to rewrite a bit of code, one must ensure the rewrite will satisfy its contract with all of its callers.
yes, i can totally appreciate this. i've been on projects where not-very-technical management suddenly decides it wants to focus on reducing the amount of code duplication, as that's a goal and metric that can be talked about while only having a superficial understanding of what's actually going on in the codebase. for codebases with swathes of low-quality code and poor automated test coverage, trying to couple everything together unnecessarily for the goal of "code reuse" can turn out to be a nightmare: a lot of previously unrelated components without solid regression test coverage suddenly depend upon some poorly designed bug-ridden common dependency with a broken abstraction that is constantly getting patched by developers who are touching one or more of the leaf systems that depend upon it.
It's focus is not on constant refactoring but constant rewriting. Turns out easily rewritable code means easily deletable code. I think the major drawback of this approach is it's hard to follow for systems where you don't yet have some kind of intuitive sense of how the low level implementation requirements since you end up leaving those for last.