It's hard to say no to your customers, but I'm getting a lot of practice at it.
You see, almost every day I say no when a customer asks me to add a feature to FeedDemon. It's not that I don't want them to be happy – it's just that every feature I add to FeedDemon potentially makes it more complicated for every customer, so I have to shoot down features that I don't believe will be widely used.
Quite often, the customer will reply with, "well, why not just make it an option?" Which of course makes sense when you're thinking about one little feature. I mean, how could adding one measly checkbox tucked away in the program's settings make it more complicated? But multiply that by the number of feature requests I get, and it becomes clear that making everything an option is, well, not an option.
I wasn't always this way. Many years ago when I worked on HomeSite (and, to some extent, TopStyle), I'd say "yes!" to feature requests all the time. If the feature wasn't one that a ton of people wanted, I'd just make it an option. I thought this was great – and at first, it was. Customers got new stuff all the time, and loved seeing their suggestions included in the product. But fast forward a few years, and suddenly my software was an option-laden monstrosity.
In a misguided attempt to please everyone, I had added page after page of checkboxes to the options dialog. Customers kept asking for options that already existed, or wondered where an option was that they knew was there but couldn't find in the checkbox maze. Even worse, they'd inadvertently enable some option that changed the program's behavior, and then report that the software no longer worked like it was supposed to. Which meant that when I received a bug report, I'd have to figure out which options might be involved in the bug, and then figure out which of those options the customer had enabled.
The other thing is, while it's easy to add an option, it's very hard to take it away. If you add an option to your software, you'd better be prepared to keep it around for the life of the product unless you want customers coming after you with pitchforks and torches.
For example, in the first version of FeedDemon, I added a few options that made sense at the time, but later on weren't being used much and were complicating the development of new versions. So in the first few beta versions of FeedDemon 4.0, I did away with some options that had existed for years. To say this wasn't received well would be an understatement. Customers who had become used to these options were up in arms, and said they'd never upgrade if the options weren't returned. It's pretty frustrating for a developer to hear that all the work done to improve a product is overshadowed by the loss of a few options that probably shouldn't have been added in the first place.
So if you're a developer and you're working on a new piece of software, don't make my mistake of adding options, especially if you're doing so just to please a handful of power users. In fact, see if you can avoid the need for a settings dialog at all. You and your customers will be happier in the long run.