4 ms·

I disagree. I think this is the same "mechanism, not policy" debate repackaged, and I certainly think mechanism is better than policy, where the author of the

I disagree. I think this is the same "mechanism, not policy" debate repackaged, and I certainly think mechanism is better than policy, where the author of the post thinks otherwise. That said, I think that going all-in on "mechanism, not policy" is a mistake too. I believe there is a middle ground: focusing on mechanism, but providing a sane default policy that lets the user get stuff done fast and change things later if they need to. I wrote more about this idea in https://gavinhoward.com/2021/03/lessons-learned-as-a-user-1-ease-matters/ https://gavinhoward.com/2021/03/lessons-learned-as-a-user-1-... .

taeric 6y ago
Reading your post, it brings to mind that a lot of this is around what we are controlling. As a physical example, I can't remember the last time we had to educate people on how to "pump your brakes" in the rain. Turns out, there are flat out better mechanisms to control for some of these things. I suspect many lane assist technologies and other mechanisms to eventually grow to eclipse environments that lack them. But, bringing that back to the software world is hard. There are things that we don't give a second thought to in a lot of what we do. Endianness is an easy example of something that you used to not be able to avoid. How do we get more of our concerns across that line? Can we?
- ghoward 6y ago
  You make great points. However, I still have learned how to pump brakes in rain, and I taught it to my wife. The reason is that the better mechanism, anti-lock braking systems in this case, can always fail. Joel Spolsky had a whole post about this: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... . If we only teach the happy path, we are setting ourselves and everyone else up for failure when the happy path fails, which it will. As another counterpoint, there is so much automation in modern airplanes that pilots are relying too much on the automation and losing their basic airmanship skills. (https://www.nbcnews.com/news/us-news/airline-pilots-depend-too-much-automation-says-panel-commissioned-faa-flna2D11625301 https://www.nbcnews.com/news/us-news/airline-pilots-depend-t...) I think the same problem is starting to show in all of the assist technologies in cars. People are starting to rely more on those technologies than they should. Basically, at some point, putting more concerns across the line is a bad idea because we will eventually lose the ability to handle things when they go wrong. We also lose institutional knowledge. (https://www.youtube.com/watch?v=ZSRHeXYDLko https://www.youtube.com/watch?v=ZSRHeXYDLko)
  - taeric 6y ago
    I feel this fits things that "aren't really wrong", but that are dangerous. Other examples include monoculture of crops. Generally, not a good idea. Happens wherever it can, though. That is, I agree with your points. I just have difficulty thinking we have the full picture covered. :(
  - Rule35 6y ago
    > I think the same problem is starting to show in all of the assist technologies in cars. People are starting to rely more on those technologies than they should. Have you seen the commercials where someone is driving and almost gets everyone killed by taking their eyes off the road. The system slams them to a halt, barely saving them, and the parent happily smiles - family safe, nothing to learn here. In one commercial, the parent is supposed to be teaching their child to drive. These driving aids should work differently. If they ever have to emergency-brake to save you they should immediately activate a small packet of thermite in the ECU, rendering the car into a brick. You proved you can't use it safely so you shouldn't have it. It would be different if these devices worked, but they don't. They just tell you that your lack of skill is okay.
    - ghoward 6y ago
      That last two sentences sum it all up perfectly.
gregmac 6y ago
> I believe there is a middle ground: focusing on mechanism, but providing a sane default policy that lets the user get stuff done fast and change things later if they need to. I agree with this. I see parallels to a lot of frameworks, languages, libraries, etc: the "getting started" guide is fairly simple, but then to do a "real" thing with it, you need to basically throw all that away and learn a whole different system. The other mistake a lot of systems make is abstracting away the complexity with defaults (aka "magic"), but making it so if you do want to change one thing you have to learn and re-implement the entire configuration yourself. In both cases, it's the learning curve that is important to think about: going from usable defaults (beginner) to customization (expert) should not be one giant all-or-nothing step.

taeric 6y ago

Reading your post, it brings to mind that a lot of this is around what we are controlling. As a physical example, I can't remember the last time we had to educate people on how to "pump your brakes" in the rain. Turns out, there are flat out better mechanisms to control for some of these things. I suspect many lane assist technologies and other mechanisms to eventually grow to eclipse environments that lack them. But, bringing that back to the software world is hard. There are things that we don't give a second thought to in a lot of what we do. Endianness is an easy example of something that you used to not be able to avoid. How do we get more of our concerns across that line? Can we?

ghoward 6y ago
You make great points. However, I still have learned how to pump brakes in rain, and I taught it to my wife. The reason is that the better mechanism, anti-lock braking systems in this case, can always fail. Joel Spolsky had a whole post about this: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... . If we only teach the happy path, we are setting ourselves and everyone else up for failure when the happy path fails, which it will. As another counterpoint, there is so much automation in modern airplanes that pilots are relying too much on the automation and losing their basic airmanship skills. (https://www.nbcnews.com/news/us-news/airline-pilots-depend-too-much-automation-says-panel-commissioned-faa-flna2D11625301 https://www.nbcnews.com/news/us-news/airline-pilots-depend-t...) I think the same problem is starting to show in all of the assist technologies in cars. People are starting to rely more on those technologies than they should. Basically, at some point, putting more concerns across the line is a bad idea because we will eventually lose the ability to handle things when they go wrong. We also lose institutional knowledge. (https://www.youtube.com/watch?v=ZSRHeXYDLko https://www.youtube.com/watch?v=ZSRHeXYDLko)
- taeric 6y ago
  I feel this fits things that "aren't really wrong", but that are dangerous. Other examples include monoculture of crops. Generally, not a good idea. Happens wherever it can, though. That is, I agree with your points. I just have difficulty thinking we have the full picture covered. :(
- Rule35 6y ago
  > I think the same problem is starting to show in all of the assist technologies in cars. People are starting to rely more on those technologies than they should. Have you seen the commercials where someone is driving and almost gets everyone killed by taking their eyes off the road. The system slams them to a halt, barely saving them, and the parent happily smiles - family safe, nothing to learn here. In one commercial, the parent is supposed to be teaching their child to drive. These driving aids should work differently. If they ever have to emergency-brake to save you they should immediately activate a small packet of thermite in the ECU, rendering the car into a brick. You proved you can't use it safely so you shouldn't have it. It would be different if these devices worked, but they don't. They just tell you that your lack of skill is okay.
  - ghoward 6y ago
    That last two sentences sum it all up perfectly.

gregmac 6y ago

> I believe there is a middle ground: focusing on mechanism, but providing a sane default policy that lets the user get stuff done fast and change things later if they need to. I agree with this. I see parallels to a lot of frameworks, languages, libraries, etc: the "getting started" guide is fairly simple, but then to do a "real" thing with it, you need to basically throw all that away and learn a whole different system. The other mistake a lot of systems make is abstracting away the complexity with defaults (aka "magic"), but making it so if you do want to change one thing you have to learn and re-implement the entire configuration yourself. In both cases, it's the learning curve that is important to think about: going from usable defaults (beginner) to customization (expert) should not be one giant all-or-nothing step.