4 ms·

at some point you gotta start engineering a solution instead of just adding to the list of flags.. isn't that what engineers are supposed to do? Seems like the

at some point you gotta start engineering a solution instead of just adding to the list of flags.. isn't that what engineers are supposed to do? Seems like they got themselves into a tech debt situation now

version_five 4y ago
I was just thinking that in my own code I have a tendency to add more command line arguments as a quick fix and then (hopefully) go back and limit them to what is essential and add config files if necessary, etc. It does seem like a sign that too many people are able to come in and do some debugging or experiment via flags, without cleaning up afterwards.
cpncrunch 4y ago
Well it's either flags, or a config file (firefox's user.js). Just two different ways of achieving the same thing. Browsers are complex these days, and it's good that we have options to change behaviour that is problematic for us. I run chrome/firefox as part of a batch job on a virtual linux display, so I really need to turn off all the crap like first-start wizards, bookmarks and the like.
- zefix 4y ago
  > Well it's either flags, or a config file Actually: No. Well, at least not in the ridiculous way that Chrome or Firefox do it. Command line options or config files are both fine - when used in moderation. The problem here (at least in part) is that it is extremely easy for devs to just add a configuration option. But it is much harder to think about whether a user would actually ever want to change the setting, if it had a good default value. In fact, I think maybe about 20 command line options would cover 99.9% of all usecases for chrome. - And it would be so much more understandable. - Both for the actual developers and the users. I absolutely despise it when a software product pushes effort downstream this way. --- Note: I fully understand that in Chrome these flags at least partially leak out of their "trunk-driven development". - But this is no excuse: In no way should the development environment leak out into a released product this way! - And it would be exceptionally easy to stop this too: Just disable all development flags in the release build.
drpixie 4y ago
Yeah - my first thought, on seeing the list, "the project is completely out of control and it's amazing that it works as well as it does!" I guess it's a tribute to what you can get if you throw enough money and effort at something! They must be running flat-out just keeping the project going and the ever-changing product running. Just imagine what they could have done with that money & effort, if it was spent on clear, focused projects.
- jeffbee 4y ago
  If you see evidence like this that conflicts with your prejudices, it should make you rethink your prejudices, not denounce the evidence. Facts we are aware of: Chrome is an extremely successful project with many users and developers, and it uses flag-oriented feature control. Your prejudice: flag-oriented feature switches are "out of control". Now, how are you going to reconcile this? Doesn't it call into question the utility of your prejudice? This is demonstrably an extremely successful project that ignores your rule.
  - drpixie 4y ago
    I've been around enough projects to pick up on warning signs :) That google has been able to manage such a project is truly impressive. Chrome is clearly the most popular browser out there but, for me, popularity counts for little. Chrome is also extremely heavyweight by most measures (installed size, memory usage, cpu usage, build time!) Re popularity: Imagine you're at a retail store buying a coffee maker. They tell you "this model is very popular". For something that people purchase/install occasionally, popularity isn't a good indicator of quality, though it might be a good indicator of price, advertising, feature-list, or sales commission! Personally, I want my coffee maker to make great coffee, and to keep doing that for a long time. And I want my browser to be fast, lightweight, and minimally intrusive.
    - joshuamorton 4y ago
      The "it uses lots of memory" argument is sort of silly. That's the behavior you want. Unused ram is wasted, as long as chrome is willing to play nice and free it, using otherwise unused memory to prefetch/cache is good user experience.
btown 4y ago
Counterpoint: well-designed feature flags encourage good design and modularity. Rather than sneaking my hacks all over the codebase, if I’m going to sneak a non-backwards compatible change somewhere, I’ll need to explicitly put it behind my feature flag, and it’s immediately apparent not only to reviewers but also future maintainers that my feature is the one that changed behavior. It’s also documentation: this is why this change is necessary. And removing a flag, even when the feature is stable, removes those guardrails.
- missblit 4y ago
  Counter counterpoint: Chrome also has an entire system for gating features behind flags without needing to write a new command line flag for each one. Counter counter counterpoint: I like command line flags and you can take them from my cold dead hands.
  - btown 4y ago
    If it doesn't hail from the command line flag region of France, can it really be called a feature, or is it just sparkling technical debt?
Wowfunhappy 4y ago
What is the alternative? Make them compile-time options? Expose them to the UI? For all sorts of testing reasons, there has to be a way to disable the JIT. There has to be a way to disable sandboxing. There has to be a way to bypass the GPU acceleration blacklist, and there has to be a way to launch without GPU acceleration on non-blacklisted hardware. Thank god the options exist! I mostly wish the documentation was better. It would be great if I could filter by platform. And, um, the definitive source probably shouldn't be some guy's personal website.
- zefix 4y ago
  The alternative is to not have (most of them) at all. The reality is that 99.5% of users have perhaps 10 or 20 actual usecases/requrements. - You named a few of the most prominent ones. These need to be supported (e.g. with flags) and documented properly. Everything else is excess can be removed. The problem with this is: You need to find out what users want to do. But many software projects are just too lazy and push all the effort downstream.

version_five 4y ago

I was just thinking that in my own code I have a tendency to add more command line arguments as a quick fix and then (hopefully) go back and limit them to what is essential and add config files if necessary, etc. It does seem like a sign that too many people are able to come in and do some debugging or experiment via flags, without cleaning up afterwards.

cpncrunch 4y ago

Well it's either flags, or a config file (firefox's user.js). Just two different ways of achieving the same thing. Browsers are complex these days, and it's good that we have options to change behaviour that is problematic for us. I run chrome/firefox as part of a batch job on a virtual linux display, so I really need to turn off all the crap like first-start wizards, bookmarks and the like.

zefix 4y ago
> Well it's either flags, or a config file Actually: No. Well, at least not in the ridiculous way that Chrome or Firefox do it. Command line options or config files are both fine - when used in moderation. The problem here (at least in part) is that it is extremely easy for devs to just add a configuration option. But it is much harder to think about whether a user would actually ever want to change the setting, if it had a good default value. In fact, I think maybe about 20 command line options would cover 99.9% of all usecases for chrome. - And it would be so much more understandable. - Both for the actual developers and the users. I absolutely despise it when a software product pushes effort downstream this way. --- Note: I fully understand that in Chrome these flags at least partially leak out of their "trunk-driven development". - But this is no excuse: In no way should the development environment leak out into a released product this way! - And it would be exceptionally easy to stop this too: Just disable all development flags in the release build.

drpixie 4y ago

Yeah - my first thought, on seeing the list, "the project is completely out of control and it's amazing that it works as well as it does!" I guess it's a tribute to what you can get if you throw enough money and effort at something! They must be running flat-out just keeping the project going and the ever-changing product running. Just imagine what they could have done with that money & effort, if it was spent on clear, focused projects.

jeffbee 4y ago
If you see evidence like this that conflicts with your prejudices, it should make you rethink your prejudices, not denounce the evidence. Facts we are aware of: Chrome is an extremely successful project with many users and developers, and it uses flag-oriented feature control. Your prejudice: flag-oriented feature switches are "out of control". Now, how are you going to reconcile this? Doesn't it call into question the utility of your prejudice? This is demonstrably an extremely successful project that ignores your rule.
- drpixie 4y ago
  I've been around enough projects to pick up on warning signs :) That google has been able to manage such a project is truly impressive. Chrome is clearly the most popular browser out there but, for me, popularity counts for little. Chrome is also extremely heavyweight by most measures (installed size, memory usage, cpu usage, build time!) Re popularity: Imagine you're at a retail store buying a coffee maker. They tell you "this model is very popular". For something that people purchase/install occasionally, popularity isn't a good indicator of quality, though it might be a good indicator of price, advertising, feature-list, or sales commission! Personally, I want my coffee maker to make great coffee, and to keep doing that for a long time. And I want my browser to be fast, lightweight, and minimally intrusive.
  - joshuamorton 4y ago
    The "it uses lots of memory" argument is sort of silly. That's the behavior you want. Unused ram is wasted, as long as chrome is willing to play nice and free it, using otherwise unused memory to prefetch/cache is good user experience.

btown 4y ago

Counterpoint: well-designed feature flags encourage good design and modularity. Rather than sneaking my hacks all over the codebase, if I’m going to sneak a non-backwards compatible change somewhere, I’ll need to explicitly put it behind my feature flag, and it’s immediately apparent not only to reviewers but also future maintainers that my feature is the one that changed behavior. It’s also documentation: this is why this change is necessary. And removing a flag, even when the feature is stable, removes those guardrails.

missblit 4y ago
Counter counterpoint: Chrome also has an entire system for gating features behind flags without needing to write a new command line flag for each one. Counter counter counterpoint: I like command line flags and you can take them from my cold dead hands.
- btown 4y ago
  If it doesn't hail from the command line flag region of France, can it really be called a feature, or is it just sparkling technical debt?

Wowfunhappy 4y ago

What is the alternative? Make them compile-time options? Expose them to the UI? For all sorts of testing reasons, there has to be a way to disable the JIT. There has to be a way to disable sandboxing. There has to be a way to bypass the GPU acceleration blacklist, and there has to be a way to launch without GPU acceleration on non-blacklisted hardware. Thank god the options exist! I mostly wish the documentation was better. It would be great if I could filter by platform. And, um, the definitive source probably shouldn't be some guy's personal website.

zefix 4y ago
The alternative is to not have (most of them) at all. The reality is that 99.5% of users have perhaps 10 or 20 actual usecases/requrements. - You named a few of the most prominent ones. These need to be supported (e.g. with flags) and documented properly. Everything else is excess can be removed. The problem with this is: You need to find out what users want to do. But many software projects are just too lazy and push all the effort downstream.