There’s a spectrum of things you can hold in your head, from crude knowledge to subtle knowledge. Things like tools, frameworks, and patterns are on the crude side of the spectrum. Design principles and design qualities are on the subtle side.

Knowledge of design qualities and design principles is much harder to acquire than the more crude subjects, but that subtle knowledge is a multiplier of all the other software knowledge you have.

All of the design principles you know or have heard of are expressions of a handful of qualities. Some of the more critical qualities to have a grasp of are afference and efference, generalization and specialization, and push and pull.

For example, the Tell, Don’t Ask principle can’t be expressed directly in terms of Push, Don’t Pull, which has a more common name: encapsulation. And each one of these qualities reflects cohesion and coupling. And furthermore, cohesion and coupling are inter-related and affect each other. Afference and efference are kinds of coupling. Afference is inbound coupling, and efference is outbound coupling.

All of these qualities direct how or when a particular tool or framework or pattern should be used. They keep you from mistakes like using the wrong tool, or using a tool in a way that violates design principles.

Without belaboring the details of what each one of these qualities means and the specifics of their impacts on design, it should be said that protecting developer productivity is the whole point of focus on design principles and design qualities.

It all boils down to adverse coupling. Coupling is the quality that dictates whether a team can move through its work without hindrance, or whether it will be bogged down.

It should also be said that adverse coupling is not a naturally-occurring phenomenon. Software doesn’t rot like a physical material. If it exists, it’s because developers put it there. And it’s unlikely that developers would willfully sabotage themselves and their own work. Harmful coupling exists in systems because developers routinely massively underestimate its effects.

The impacts of coupling and the means to control it is a subtle subject. It takes a lot longer to bring its meaning into focus than grasping a new tool, framework, or pattern. It doesn’t take forever, but it’s not instantaneous.

Securing the productivity of a software project requires protecting the ease of change. The interplay between software qualities (as expressed by design principles, and the patterns built on them, and the frameworks built on the patterns) predicts whether a team will be hindered in making necessary changes to the implementation, or whether they will sail right through. Having a grasp of these subtleties, and keeping them in-mind in every moment, keeps software projects from becoming the grinding slog that software projects often become.

It’s the subtle knowledge that keeps us from making predictable mistakes. It doesn’t so much help us to remediate past mistakes, because that cost is already sunk. The best we can do is sharpen up our design senses so that we don’t invite these mistakes; to sharpen our sense of the subtle so that it is no longer out-of-reach.

Design is subtle knowledge. It helps us to recognize the well-known, but subtle mistakes before they become calcified beneath weeks, months, or years of further development, and keeps the mistakes from amplifying each other.

Knowledge of design qualities and design principles is the most powerful knowledge you can have. It activates and amplifies your knowledge of the more crude and material things–the tools, frameworks, patterns, and even languages. It doesn’t obviate the need for more crude knowledge, but it does complete that crude knowledge and allow you to wield it in much more precise and deterministic ways.

Subtle knowledge makes it clear how you should use tools. It helps you avoid the traps that otherwise might suck you in — especially those that are merely prominent or fashionable, and that you’ll regret in the future as the subtleties are slowly revealed to you through series of unfortunate mistakes.

And while subtle knowledge isn’t as readily available as the crude subjects that can be materially transferred, merely by cultivating an interest in this body of knowledge and paying attention to it, you’ll start the process of opening up the other side of software development knowledge that makes everything you do more effective.