Also, your job (or at least my job) is building long-term value for the shareholders of your company. Satisfying customers in the short term is just a part of that. Maybe we have different perspectives because we have different backgrounds? I've not done anything like a payroll for a single big customer; I've always had lots of little customers. -- DaveHarris
My "customers" over the past 35 years or so have generally had a specific deliverable in mind by a specific date. Your situation may be different.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.