Your points about garbage code are interesting, and I think there's much to be said for that strategy. Regarding your first sentence, you should be frequently

Your points about garbage code are interesting, and I think there's much to be said for that strategy. Regarding your first sentence, you should be frequently spinning off chunks of code, but you should be careful that you're not adding coupling where it doesn't exist in the domain. Again, I like the knowledge formulation of DRY. "This is the way we render a FOO" is one piece of knowledge, and shouldn't be repeated every time you try to render a FOO. "There should be a FOO rendered here" is one piece of knowledge, and shouldn't be repeated at multiple layers in your stack. Now... what if we've been good about the above, but there's some similar code in "how we render a FOO" and "how we render a BAR"? If the code is similar because we want a consistent style across FOO and BAR, then "we want such-and-such a style" is a piece of knowledge, and it should be represented in one place! If the code is similar, but only coincidentally, and either might change in any direction tomorrow, then there's a question: "Is it a coherent abstraction?" We want abstractions such that we can give them a clear name, such that when we make a change to how we render only FOO or BAR we'll be obviously moving to a new abstraction and won't be tempted to change the function, and such that we know to reach for this function when it's applicable in a new context. Alternatively, is it just a gathering of a particular grab bag of functionality? If you're pulling that out, you're not improving your code - you're compressing it.