I think people should prevent themselves from using words like "abstraction", "scale" and "powerful" when they really want to talk about something. > Designing

I think people should prevent themselves from using words like "abstraction", "scale" and "powerful" when they really want to talk about something. > Designing complex conceptual structure is basically what software engineering really is You cannot quote Brooks and assume that you are going to do something complex anyway. Otherwise you fall for the most common form of accidental complexity: sloppiness. It doesn't have to be complex. Assuming it is going to be complex is the wrong default value. But really what the author is talking about is API design. The only way for a library or framework to reduce the essential complexity is to skip on some aspects (not implementation details - this would be an abstraction). Like making variables constants so users don't have to fill in weird parameters only an expert of the domain would know what they are about. This is precisely those choices that matter in API design. If you don't make those choices, you end up with a complex API through which you can see all the details (remember the trend of devices with transparent shells in the 90ies? That's the image). So you make choices. There's some things your users won't be able to do because your API fill in the annoying variables for them. But of course "One man's constant is another man's variable" (applies to women too) so may you'll have to present different interfaces or sub-APIs. This is interface segregation.