3 ms·

Hey now, the preferences panels of yore were glorious outposts of customization and power-user-centric software. Computing was way more fun back then. Don't lum

• _jal 6y ago
  That approach to preferences tends to cause combinatorial explosions in your QA department. You can do it if you're careful, but being careful is the opposite of the "then just make it a preference" approach.
• mwfunk 6y ago
  I'm not against preferences and lots of options in general when appropriate, I just don't think they're zero-cost. It's like the surprisingly huge difference between a service being "free" vs. "almost free". But anecdotally (I know...) when fundamental differences between developers are resolved as, "let's just do both and make it an option", it's either people assuming that allowing both behaviors either has no cost, or it's a failure to resolve differences that inflicts one of the thousand tiny cuts that will someday overwhelm the code base. At the same time, I don't want to be dogmatic about anything, those are just general tendencies. Emacs for example is a beautiful example of an almost opposite design. The software is like a computing instrument that the user has to first learn how to play, but the more effort they put in to it, (up to a point at least, and depending on what they want to do) the more they get out of it. Ultimately it depends on what you're trying to accomplish and who your users are.