That's the right way.
"Never really remove anything, just wrap it in a default-off config option" is a horrendously bad way to build software. Every configurable option is an opportunity for bugs and an opportunity for misconfiguration.
That's the right way.
"Never really remove anything, just wrap it in a default-off config option" is a horrendously bad way to build software. Every configurable option is an opportunity for bugs and an opportunity for misconfiguration.
It's the lazy way.
You're right that it adds complexity. Every line of code contributes to complexity, and increases the number of places a bug could manifest. That's just the nature of software development.
Most software doesn't exist in a bubble of strictly-defined use cases. Software such as web browsers target a huge (potentially the broadest) range of users. Driving towards the lowest common denominator, as Google have been doing with Chrome by stripping configuration options over the years, doesn't result in a product people love to use. It produces software that performs adequately for the majority, and nothing more.
For features like "backspace to navigate back", throw them behind a flag. Make them default-disabled. Don't even worry about putting it in Preferences - tell power users who need it where they can find it (chrome://flags).
Not every feature is good or widely-used, and removing the ones that fail, rather than trying to keep them around but configurable, is simply the right thing to do.
If I deliberately reenable backspace as 'Back in browser history', I've no right to complain if I lose web app state; and if I get burned often, I'll disable it again. If I use it without any problems, what's the lose on Google's side?
Less code base to cover. Less tests. That's a win for the secs. And you're free to install an extension to retrieve the behavior of you want. Sounds like everyone wins.
Well, I'm free to install extensions on my own personal computer but not everywhere that I use Chrome.
In this case, the shortcut is being removed because it's often unintentionally triggered by people who are not familiar with it, however there are also a lot of people who intentionally use it frequently. It could be reasonably argued that something like that should be configurable.
This is the equivalent of hoisting a white flag. Theres tons of code added to Chrome all the time, it doesn't add configuration options but it sure as hell has the very same effect.
For instance, any code like
x = some_result()
if is_valid(x):
do_stuff_with(x)
is indisputably an opportunity for bugs. Better would be some construct like "if let" in Swift or Rust, where you can't use x without the condition. For instance, this was the fundamental cause of Apple's "goto fail" vulnerability: the language / API style required that they check each result and run a conditional branch on their own. (The proximate cause was bad language syntax, but the opportunity for bad syntax shouldn't have been there in the first place.)