As a software architect, I can tell you that complexity is bad. For architects, there are two types of complexity; accidental complexity and essential complexit

As a software architect, I can tell you that complexity is bad. For architects, there are two types of complexity; accidental complexity and essential complexity. The latter is inherent in the problem in that reducing essential complexity means that you are not solving the problem that you are supposed to be solving. When I say problem, I don't just mean the functional requirements. I also mean the so-called non-functional requirements. If you are familiar with use cases or user stories, then you know of functional requirements. Non-functional requirements can take the form of Service Level Agreements but also include other metrics such as the costs to running the system and feature velocity. Accidental complexity is unnecessary to solving the problem. It is a clear win to reduce that. Often you get to the point where you still have a lot of accidental complexity but cannot affordably reduce it any more. That is when you obscure complexity. That doesn't necessarily mean adding yet another layer of abstraction. It can also mean pushing the complexity from one already existing layer to another. This can be very helpful if the layer of abstraction that you are pushing the complexity too has a lower feature velocity than the layer that you are pushing it from. I have written on this subject over at https://www.infoq.com/articles/obscuring-complexity/ https://www.infoq.com/articles/obscuring-complexity/ In this scenario, I would argue that obscuring complexity is not harmful. In fact, it can be quite helpful.