4 ms·

> You can bet your bottom dollar that the engineers building the system will have brought up the fact that something can/should be a user preference/have a powe

by kd5bjo 6y ago

> You can bet your bottom dollar that the engineers building the system will have brought up the fact that something can/should be a user preference/have a power-user shortcut/etc etc during early stages of design & development As a developer, I’ve come to respect the curse of dimensionality w.r.t. testing and quality control: every binary option doubles the number of possible user configurations, and thus the testing load. In a very concrete sense configurability leads to more buggy code, and I usually err on the side of reliability.

freepor 6y ago
Best description of this is from Jack Dorsey: you have to get the details perfect, and the only way to do that is to limit the number of details.
marcosdumay 6y ago
> every binary option doubles the number of possible user configurations, and thus the testing load Only if you assume your software is the worst possible variety of spaghetti. Configurations do increase the software complexity. By how much is a very complicated question.
- jerf 6y ago
  In theory, every additional binary configuration item doubles your state space, because you have all the old state space, but now both with that value on and off. It is tempting to say that in practice the result is less than this, but in practice, it isn't. Adding a binary option may seem not to double the state space because it only modifies a small portion of the original space. e.g., imagine an option that the user sets to force all emails to be in ALL CAPS. Strong abstractions can mostly contain that state space increase in a principled manner to just that email code, for instance. But if you've been doing this for ten+ years, you've almost certainly encountered the moral equivalent three other supposedly equally-well contained things interacting to produce a bug. Maybe if the user set this setting to true, and was using your UI in Armenian, and all the other settings on the page are in their longest possible form in Armenian, and your UI guy used a fixed-size frame ever so slightly incorrectly, your setting disappeared off the UI entirely, just to draw one example out, even though you had a "proof" that this setting couldn't affect anything but the email code. Any number of other ways this could go wrong. None of our tools are good enough to fully contain the exponential state space explosion exponentially correctly, and it will sooner or later push through your best efforts to contain it. One of the best ways to prevent this is just not to feed the exponential monster.
  - hinkley 6y ago
    If you look at what happens with Refactoring or Unit testing, instead of just listening to what people tell you is happening, you see that a lot of goes on is synthesizing one state from a small group of others, over and over again. So for instance there may be five different criteria that decide whether you are qualified to receive a 10% off discount. You make a block of code that is responsible for emitting a single boolean, and the rest of the system only ever interacts with that single value. Instead of an upper bound of 2^n you have one that is somewhere around n/3 factorial. Which is still a scary-big number, but might push out the dog leg a couple of years.
    - kd5bjo 6y ago
      > instead of just listening to what people tell you is happening Can you elaborate on what you’re referring to with this phrase? As far as I can tell, everyone here is reasoning from their personal experiences rather than adopting the opinions of others.
      - hinkley 6y ago
        Ah, I meant 'in the literature' not in the thread. Just commenting on the frequent disconnect between 'why we do things' and why we do things.
- hinkley 6y ago
  > Only if you assume your software is the worst possible variety of spaghetti. Gravity always wins. The thing about exponentials that if the constant is > 1 the trend line essentially looks the same, the X axis just changes a bit. So maybe a boolean doesn't double the surface area, maybe it's only 1.5, that still results in compound interest. Even at 1.1, it only takes 7 booleans to double your surface area.
  - marcosdumay 6y ago
    Yet, everything interesting happens on the border where things are falling but still not irreversibly so. Yes, if you leave them wild options will overwhelm your code. The entire field of software engineering is focused on solving that exact problem; what people can do, with varying degrees of success.
    - kd5bjo 6y ago
      The initial cost is quite low and there are techniques to reduce the growth factor, but I’ve seen no evidence of anything that reduces this below an exponential scenario. Over large scales, exponentials can be reasonably modeled by a piecewise function that’s 0 below some threshold and infinity above it (1). That translates roughly into a fixed number of options that can be maintained, modulated by your development practices. Without knowing what that limit actually is, what’s the best strategy for spending this limited resource? As there’s no such thing as an average person (2), I contend that this budget should be reserved for things that materially affect accessibility. (1) This is the standard approximation for a diode’s I-V curve, for instance (2) https://apps.dtic.mil/dtic/tr/fulltext/u2/010203.pdf https://apps.dtic.mil/dtic/tr/fulltext/u2/010203.pdf
thomastjeffery 6y ago
> every binary option doubles the number of possible user configurations This is why you distinguish UI options from functionality options. If you properly factor functionality out by modularizing UI, you end up with an order of magnitude less complexity.
- kd5bjo 6y ago
  Ok, so you’ve successfully reduced the problem space from 2^n to 2^(kn) + 2^(n-kn) , where k is the ratio of options in the two categories. That’s better, but still clearly exponential growth.

by kd5bjo 6y ago

freepor 6y ago

Best description of this is from Jack Dorsey: you have to get the details perfect, and the only way to do that is to limit the number of details.

marcosdumay 6y ago

> every binary option doubles the number of possible user configurations, and thus the testing load Only if you assume your software is the worst possible variety of spaghetti. Configurations do increase the software complexity. By how much is a very complicated question.

jerf 6y ago
In theory, every additional binary configuration item doubles your state space, because you have all the old state space, but now both with that value on and off. It is tempting to say that in practice the result is less than this, but in practice, it isn't. Adding a binary option may seem not to double the state space because it only modifies a small portion of the original space. e.g., imagine an option that the user sets to force all emails to be in ALL CAPS. Strong abstractions can mostly contain that state space increase in a principled manner to just that email code, for instance. But if you've been doing this for ten+ years, you've almost certainly encountered the moral equivalent three other supposedly equally-well contained things interacting to produce a bug. Maybe if the user set this setting to true, and was using your UI in Armenian, and all the other settings on the page are in their longest possible form in Armenian, and your UI guy used a fixed-size frame ever so slightly incorrectly, your setting disappeared off the UI entirely, just to draw one example out, even though you had a "proof" that this setting couldn't affect anything but the email code. Any number of other ways this could go wrong. None of our tools are good enough to fully contain the exponential state space explosion exponentially correctly, and it will sooner or later push through your best efforts to contain it. One of the best ways to prevent this is just not to feed the exponential monster.
- hinkley 6y ago
  If you look at what happens with Refactoring or Unit testing, instead of just listening to what people tell you is happening, you see that a lot of goes on is synthesizing one state from a small group of others, over and over again. So for instance there may be five different criteria that decide whether you are qualified to receive a 10% off discount. You make a block of code that is responsible for emitting a single boolean, and the rest of the system only ever interacts with that single value. Instead of an upper bound of 2^n you have one that is somewhere around n/3 factorial. Which is still a scary-big number, but might push out the dog leg a couple of years.
  - kd5bjo 6y ago
    > instead of just listening to what people tell you is happening Can you elaborate on what you’re referring to with this phrase? As far as I can tell, everyone here is reasoning from their personal experiences rather than adopting the opinions of others.
    - hinkley 6y ago
      Ah, I meant 'in the literature' not in the thread. Just commenting on the frequent disconnect between 'why we do things' and why we do things.
hinkley 6y ago
> Only if you assume your software is the worst possible variety of spaghetti. Gravity always wins. The thing about exponentials that if the constant is > 1 the trend line essentially looks the same, the X axis just changes a bit. So maybe a boolean doesn't double the surface area, maybe it's only 1.5, that still results in compound interest. Even at 1.1, it only takes 7 booleans to double your surface area.
- marcosdumay 6y ago
  Yet, everything interesting happens on the border where things are falling but still not irreversibly so. Yes, if you leave them wild options will overwhelm your code. The entire field of software engineering is focused on solving that exact problem; what people can do, with varying degrees of success.
  - kd5bjo 6y ago
    The initial cost is quite low and there are techniques to reduce the growth factor, but I’ve seen no evidence of anything that reduces this below an exponential scenario. Over large scales, exponentials can be reasonably modeled by a piecewise function that’s 0 below some threshold and infinity above it (1). That translates roughly into a fixed number of options that can be maintained, modulated by your development practices. Without knowing what that limit actually is, what’s the best strategy for spending this limited resource? As there’s no such thing as an average person (2), I contend that this budget should be reserved for things that materially affect accessibility. (1) This is the standard approximation for a diode’s I-V curve, for instance (2) https://apps.dtic.mil/dtic/tr/fulltext/u2/010203.pdf https://apps.dtic.mil/dtic/tr/fulltext/u2/010203.pdf

thomastjeffery 6y ago

> every binary option doubles the number of possible user configurations This is why you distinguish UI options from functionality options. If you properly factor functionality out by modularizing UI, you end up with an order of magnitude less complexity.

kd5bjo 6y ago
Ok, so you’ve successfully reduced the problem space from 2^n to 2^(kn) + 2^(n-kn) , where k is the ratio of options in the two categories. That’s better, but still clearly exponential growth.