Overall it's about finding new generalizations and collapse your extensive complexity by new abstraction.

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.

I really liked the simplicity of your explanation and it makes total sense to me. I checked your blog and you have some interesting articles but most I can't read. I think it is time to start rescuing the insights of software engineering practitioners with several decades experience to go beyond the fads of the day. I feel that some of the old agile ideas/principles are lost in the noise. (e.g Do The Simplest Thing That Could Possibly Work)

Thank you :) You can check my articles in English here https://fibery.io/blog/

Well explained.

Thank you!

Given a programming context we are always writing code on an abstraction layer, such a layer (which can be as granular as a language construct or a function) can accommodate features. We essentially encode our feature in terms of the given abstraction(s).

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.