For example, you build a Todo-list software (everybody does). You have requests from customers "I want to be notified 3 days before due date", "I want to be notified 1 day before due date" and "I don't need notifications".

OK, so you are adding a new setting "[ON/OFF] Notify me [X] days before due date".

Then you get feedback "I want to be notified when someone unassigned me" and "I want to be notified when someone assigns me".

OK. You're adding new setting "[ON/OF] Notify me about changes of my assignments"

Then you receive feedback like "I want to be notified about important tasks assigned to me only".

You say "Fuck it" and implement a notification engine where every user can set up own notification rules.

X notifications settings were collapsed into a new more abstract (but more complex) solution. You have to choose abstractions carefully and be aware that premature abstractization is as bad as premature optimization. This is hard.

Now I didn't read the book but I immediately thought of this: If we want to provide a feature, we should think of how our abstractions accommodate the feature. Are the assumptions or the interface of the abstractions in line with the functionality, or guarantees of the feature?

A good example of this would be HTTP REST. The interface is general and has clear, well defined semantics. It is a good abstraction for the web, since every request/response cycle has a clear way of reaching possible states and resources. It accommodates new features very well if they can be encoded in terms of HTTP verbs, hypertext representation and request/response cycles.