Moved from YouArentGonnaNeedIt
Ask customers (and yourself) this question: "How much of my time and your money should I invest in putting things into the system that do not make it better?"
Then ask: "How much of my time and your money should I invest in putting things into the system that I think might make it better?"
This is the key notion: putting in code that is anticipated to be useful is risky (because we might be wrong), and wasteful (because it does today what could just as well be done tomorrow). Our rule is Just A Rule, but starting there helps err on the side of our current known requirements, not on some unknown future. We think that's a good thing.
We aren't talking about building flimsy, poorly-factored classes, we're just saying that we don't give them features that aren't called for by our current requirements. We rely on the ability to refactor well-crafted classes to provide more capability later.
Perhaps Dave's concern is that when you have a company with lots of small clients you need to focus a lot on building reusable frameworks so that your per-client-development costs are drastically reduced. If so, then YagniAndFrameworks might offer some relevant discussion.