> because there are often different possible decompositions of functions into legitimate "one things" at distinct granularities. Actually, it's fairly well est

> because there are often different possible decompositions of functions into legitimate "one things" at distinct granularities. Actually, it's fairly well established. DRY: Don't repeat yourself. Yes, if you need to assign 50 values, and each is unique, than breaking them up might be difficult. However, these aren't the rules. These are the exceptions. Heck, even your graph example could be an exception. However, in my experience, most code does contain hits on how things can be broken up into smaller, more manageable pieces. > the coarse decomposition is arguably better than the finer-grained one =) The finer-grained one is arguably better than the coarse decomposition because it removes repeated lines of code and makes it easier to test the smaller methods. That the total number of lines of code is increase is unimportant, because you rarely look at all the total code in a module. Rather, you are focused on individual components. If the individual component is smaller, it makes it easier to understand. I appreciate your point of view. And I agree, it's not easy to make things smaller without losing something. However, that doesn't mean we shouldn't try.