Add 'Abusing DRY principle' section

README.md

@@ -171,6 +171,22 @@ stuff1 // 🧠++
 
 We can focus on the happy path only, thus freeing our working memory from all sorts of preconditions.
 
+## Abusing DRY principle
+
+Do not repeat yourself - that is one of the first principles you are taught as a software engineer. It is so deeply embedded in ourselves that we can not stand the fact of a few extra lines of code. Although in general good and fundamental rule, overused leads to the complexity we can not handle.
+
+Nowadays, everyone builds software based on logically separated components. Often those are distributed among multiple codebases representing separate services. When you strive to eliminate any repetition, you might end up creating tightly coupling between unrelated components. As a result changes in one part may have unintended consequences in other seemingly unrelated areas. It can also hinder the ability to replace or modify individual components without impacting the entire system. Designing libraries with common functionalities should be done very carefully, otherwise we are losing what we aimed to have at the beginning - clear separation and independence.
+
+In fact, the same problem arises even within a single module. You might extract common functionality too early, based on perceived similarities that might not actually exist in the long run. This can result in unnecessary abstractions that are difficult to modify or extend. Generic functions often grow instead of being broken down.
+
+Rob Pike once said:
+
+> **A little copying is better than a little dependency.**  
+
+We are tempted to not reinvent the wheel so strong that we are ready to import large, heavy libraries to use a small function that we could easily write by ourselves. It introduces unnecessary dependencies and bloated code. Make informed decisions about when to import external libraries and when it is more appropriate to write concise, self-contained code snippets to accomplish smaller tasks.
+
+Ultimately, by being mindful of the DRY principle, we can write more efficient and manageable code, while abusing it could lead to indirect coupling (or just unnecessary coupling), premature abstractions and large, generic solutions, reduced readability, maintenance complexity and in some subtle cases to decreased performance.
+
 ## High coupling with a framework
 Frameworks evolve at their own pace, which in most cases doesn't match the lifecycle of our project.