4 ms·

> Good Software Does Not Expose Its Implementation Excellent goal but way harder than people think. I would say it is not possible in the fullest.

dmoy 8y ago
http://www.hyrumslaw.com/ http://www.hyrumslaw.com/
nine_k 8y ago
Good software should expose its interface, not implementation. The implementation will shine through sometimes, or will be (easily) detectable via "side-channel attacks", e.g. an interface feature can be slow due to an implementation. OTOH this allows to upgrade and entirely change the implementation without affecting the user interface, or at least while keeping it largely backwards-compatible.
Koshkin 8y ago
Indeed. Software is just like a person: what you see is an "interface," but what you are actually dealing with is the "implementation."
conradev 8y ago
Definitely not possible. The implementation becomes the interface. Classic example from when iOS/macOS had manual reference counting: fixing an over-retain bug in the framework causes the app with an over-release bug to crash. Even more extreme example: https://twitter.com/gparker/status/1050903609142009856?s=20 https://twitter.com/gparker/status/1050903609142009856?s=20
fao_ 8y ago
I kind of feel that you just read the title here. It's not talking about the 'fullest': An example of this would be if a music composition program has an easily-reached maximum song size because the code monkey who wrote it used a 16-bit variable instead of a 32-bit one. *While there are sometimes limitations that cannot be overcome*, the actual code written and the architecture used when it was written should have as little effect as possible on what the user sees and works with when using your software. (emphasis mine) I think it might be better rephrased as: 1) Don't add unnecessary constraints (or: Don't prioritise efficiency/etc. over the interface). and 2) A good interface abstracts away technical problems, rather than presenting them in a different form.
- bkmartin 8y ago
  The most common example I see is the password requirement that it must be between 8 and 16 characters... The 16 character limit is the main issue there... You know it has to do with the wya the data is stored.
  - reificator 8y ago
    It had better not...
    - hitsthings 8y ago
      And yet...
  - adrianN 8y ago
    Between 8 and 16 characters, but only 7 bit ASCII. But there is no error message if you use § in your password, it just kills the server.
    - deleted 8y ago
      [deleted]
  - Aenyn 8y ago
    At my workplace the official password policy requires /exactly/ 8 character passwords...
- emmelaich 8y ago
  I'm sure we agree 99%.
AceJohnny2 8y ago
Indeed. Also referred to as "Leaky Abstractions" Spolsky talked about it 16 years ago: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
joosters 8y ago
The most annoying (and visible) example of this is people naming their programs after the language/toolset used. As a user, I need not care that your code is written with Go/Python/KDE/Gnome, so why name your program with it?
- aepiepaey 8y ago
  Half of those don't quite belong in that list. KDE/Gnome are much more than implementation details: writing a program for either is using a certain design languages and sets of UX rules, and those are user-visible.
- jplayer01 8y ago
  Uh, it does matter though. If you're using KDE as a desktop environment, you might not want to pull in all the GTK dependencies just to run a single Gnome-based application when there's an equivalent one based on KDE. It's a common convention in Linux.
barrkel 8y ago
I don't think the goal is correct. In fact, I think the implementation should reflect the user's mental model. The closer the correspondence between the implementation's model and the user model, the less likely are surprises, bugs and limitations. There's also the aspects of form follows function, and mechanical sympathy. The use of a tool should strongly guide its shape and design, and similarly, a user should be able to develop an intuition about what the tool is good for and what it's not good for, so they can use it to maximum effectiveness, and not be frustrated when it can't cope with a problem it's not designed for.
- jalfresi 8y ago
  Totally agree. From the angle of UX and usability, the more closely the interface reflects the internal model of the system, the more accurate the users mental model of the software will be.

dmoy 8y ago

http://www.hyrumslaw.com/ http://www.hyrumslaw.com/

nine_k 8y ago

Good software should expose its interface, not implementation. The implementation will shine through sometimes, or will be (easily) detectable via "side-channel attacks", e.g. an interface feature can be slow due to an implementation. OTOH this allows to upgrade and entirely change the implementation without affecting the user interface, or at least while keeping it largely backwards-compatible.

Koshkin 8y ago

Indeed. Software is just like a person: what you see is an "interface," but what you are actually dealing with is the "implementation."

conradev 8y ago

Definitely not possible. The implementation becomes the interface. Classic example from when iOS/macOS had manual reference counting: fixing an over-retain bug in the framework causes the app with an over-release bug to crash. Even more extreme example: https://twitter.com/gparker/status/1050903609142009856?s=20 https://twitter.com/gparker/status/1050903609142009856?s=20

fao_ 8y ago

I kind of feel that you just read the title here. It's not talking about the 'fullest': An example of this would be if a music composition program has an easily-reached maximum song size because the code monkey who wrote it used a 16-bit variable instead of a 32-bit one. *While there are sometimes limitations that cannot be overcome*, the actual code written and the architecture used when it was written should have as little effect as possible on what the user sees and works with when using your software. (emphasis mine) I think it might be better rephrased as: 1) Don't add unnecessary constraints (or: Don't prioritise efficiency/etc. over the interface). and 2) A good interface abstracts away technical problems, rather than presenting them in a different form.

bkmartin 8y ago
The most common example I see is the password requirement that it must be between 8 and 16 characters... The 16 character limit is the main issue there... You know it has to do with the wya the data is stored.
- reificator 8y ago
  It had better not...
  - hitsthings 8y ago
    And yet...
- adrianN 8y ago
  Between 8 and 16 characters, but only 7 bit ASCII. But there is no error message if you use § in your password, it just kills the server.
  - deleted 8y ago
    [deleted]
- Aenyn 8y ago
  At my workplace the official password policy requires /exactly/ 8 character passwords...
emmelaich 8y ago
I'm sure we agree 99%.

AceJohnny2 8y ago

Indeed. Also referred to as "Leaky Abstractions" Spolsky talked about it 16 years ago: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

joosters 8y ago

The most annoying (and visible) example of this is people naming their programs after the language/toolset used. As a user, I need not care that your code is written with Go/Python/KDE/Gnome, so why name your program with it?

aepiepaey 8y ago
Half of those don't quite belong in that list. KDE/Gnome are much more than implementation details: writing a program for either is using a certain design languages and sets of UX rules, and those are user-visible.
jplayer01 8y ago
Uh, it does matter though. If you're using KDE as a desktop environment, you might not want to pull in all the GTK dependencies just to run a single Gnome-based application when there's an equivalent one based on KDE. It's a common convention in Linux.

barrkel 8y ago

I don't think the goal is correct. In fact, I think the implementation should reflect the user's mental model. The closer the correspondence between the implementation's model and the user model, the less likely are surprises, bugs and limitations. There's also the aspects of form follows function, and mechanical sympathy. The use of a tool should strongly guide its shape and design, and similarly, a user should be able to develop an intuition about what the tool is good for and what it's not good for, so they can use it to maximum effectiveness, and not be frustrated when it can't cope with a problem it's not designed for.

jalfresi 8y ago
Totally agree. From the angle of UX and usability, the more closely the interface reflects the internal model of the system, the more accurate the users mental model of the software will be.