4 ms·

This is missing their point. If you use a simple abstraction, you won't be able to address all of the complexity of the underlying task. You'll be sacrificing a

This is missing their point. If you use a simple abstraction, you won't be able to address all of the complexity of the underlying task. You'll be sacrificing at some point, either by leaving performance on the table or by ignoring an edge case and having it come back to bite you later. "it will work great" can only go so far without cooperation from the user, and then the complexity starts creeping back in.

arendtio 6y ago
I just read the text a 2nd time and I disagree with you. The point of the text is, that you have to define where to put the complexity: If you are lucky, it lives in well-defined places. Otherwise, it will be everywhere (obviously bad): With nowhere to go, it has to roam everywhere in your system, both in your code and in people's heads. My point, on the other hand, is that you should focus on good abstractions, which is just one more step into the direction of defining 'where the complexity should live'. When defining the abstraction you focus on the practical use-cases so that it is as simple as possible but not simpler. The main task here is to find the right focus. In doubt, it might be better to use multiple different abstractions (e.g. if there are two distinct use-cases). The goal is to find a construct where everything looks simple from the outside because the complexity is hidden by the abstraction.
- reubenmorais 6y ago
  I agree that abstraction is a useful tool in tackling complexity, but in my experience it is often the only tool people reach for, which can lead to a continuous rat chase of refactoring after refactoring, because somehow the ugly can never quite be fully hidden. This is exactly what the text talks about: shuffling of the complexity around, trying to hide it, and the end result can often be that you just don't know where it ended up. Personally I think a lot of this is due to the way software engineering ideas like "don't repeat yourself" or "design patterns" can attain an almost cult-like following, and people just blindly apply transformations instead of deeply looking at what the actual problem is. As others mentioned in the rest of this thread, complexity must be addressed, and only from a perspective of understanding what your problem is, where the traps are, what all of its complexities are, can you then come up with abstractions that will be any good.

arendtio 6y ago

I just read the text a 2nd time and I disagree with you. The point of the text is, that you have to define where to put the complexity: If you are lucky, it lives in well-defined places. Otherwise, it will be everywhere (obviously bad): With nowhere to go, it has to roam everywhere in your system, both in your code and in people's heads. My point, on the other hand, is that you should focus on good abstractions, which is just one more step into the direction of defining 'where the complexity should live'. When defining the abstraction you focus on the practical use-cases so that it is as simple as possible but not simpler. The main task here is to find the right focus. In doubt, it might be better to use multiple different abstractions (e.g. if there are two distinct use-cases). The goal is to find a construct where everything looks simple from the outside because the complexity is hidden by the abstraction.

reubenmorais 6y ago
I agree that abstraction is a useful tool in tackling complexity, but in my experience it is often the only tool people reach for, which can lead to a continuous rat chase of refactoring after refactoring, because somehow the ugly can never quite be fully hidden. This is exactly what the text talks about: shuffling of the complexity around, trying to hide it, and the end result can often be that you just don't know where it ended up. Personally I think a lot of this is due to the way software engineering ideas like "don't repeat yourself" or "design patterns" can attain an almost cult-like following, and people just blindly apply transformations instead of deeply looking at what the actual problem is. As others mentioned in the rest of this thread, complexity must be addressed, and only from a perspective of understanding what your problem is, where the traps are, what all of its complexities are, can you then come up with abstractions that will be any good.