I agree but so much depends on context. This is like arguing a painting should not have too much blue paint. But what if you're painting an ocean? In a program

I agree but so much depends on context. This is like arguing a painting should not have too much blue paint. But what if you're painting an ocean? In a programming context: - If the business process you are trying to model clearly has 20 discrete steps is would be silly break them into 4 groups of 5 steps just to hit the ideal function size. - Coming up with a good name for an abstraction in a moderately large program can be very tricky, but a poor name is hurting more than helping. Don't split it if you cannot think of a good name. - If breaking out into a function requires passing in 10 variables then it may become harder to read than simply inlining it. You're probably not abstracting correctly in that case. Etcetera. I've seen so many over-abstractions from junior programmers trying to be "clean" I wonder if these rules of thumb aren't hurting more than helping.