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 continuou

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.