In the first chapter, we introduced the concept of a tower of abstractions, and the idea that every abstraction is a simplified lever to hidden complexity. The principle of abstraction within programming states the following:

An implementation is the complex underside of an abstraction: the part that it's hiding. The interface is the simplified topside. That is why we say that abstraction is a simplified lever to hidden complexity. The craft of creating abstractions that separate implementation from interface to just the right degree is not as simple as it may seem. As such, the programming world provides two warnings for us:

• Don't repeat yourself (DRY): A warning that tells us to avoid writing code that duplicates other code we have written. If you find yourself having to repeat yourself, then this indicates that you've failed to abstract something, or have under-abstracted something.
• You aren't gonna need it (YAGNI): Also known as keep it simple, stupid! (KISS), this warning tells us to be wary of over-abstracting code that does not need to be abstracted. It's the polar opposite of DRY, and serves to remind us that we should not attempt abstraction unless it's warranted (if we start to repeat ourselves, perhaps).

Between these two warnings, somewhere in the middle, lies the perfect abstraction. Designing abstractions so that they are maximally simple and maximally useful is a balancing act. On the one hand, we can say we have under-abstraction (DRY warns us about this) and, on the other hand, we have over-abstraction (YAGNI warns us about this).