The Principle Of Applying Principles (poap)

“Have you not heard the stories? Captain Barbossa and his crew of miscreants sail from the dreaded Isla de Muerta. It’s an island that cannot be found except by those who already know where it is.”

― Jack Sparrow

I can scarcely show my head without being bombarded by principles and dogmas. Lofty goals of SOLID, DRY, and test-driven code are impressed upon me, such that I might program with the grace of the great code-prophets before me. And yet, these so-called “clean coders” all seem to struggle with two very basic things: Explaining how to actually apply the principles, and Writing code that actually works.

The more experienced and successful developers almost seem to disregard these principles and doctrines. They understand the purpose of the code, and that every good principle serves a higher purpose. They produce code that works today, and they concern themselves with maintainability issues only when and where it is actually a concern.

Now, don’t get me wrong, my frAgile friends. I believe that if we understand these principles and dogmas properly, they’re very good! From the right perspective and context, some of them may even describe the very heart of all good and sustainable solutions. But, there’s something mystical about them, isn’t there?

When a mid-level developer with full knowledge of the rules fails to routinely produce working, bloat-free solutions, and a senior-level developer with little concern for the rules produces a functional and maintainable work of art, it’s worth pausing over. It would seem that there’s something deeper than the naked text of the rules at work.

The rules lead us somewhere, but only if we already know where to go!

So, I’d like to offer a small course correction — a valuable waypoint, if you will — that I think explains how super-senior level developers intuitively do the right thing, and how novice-level “clean coders” and everyone else can better understand and apply the growing litany of principles and “best practices.”

I call it, the Principle of Applying Principles.

Or more succinctly, the POAP. Pronounced pōp. You could also call it the Principle of All Principles. In either case, it’s pronounced pōp … Like Pope. (And, God-willing, hilarity will ensue…)

But I digress …

The POAP states that,

Principles, patterns, and practices are not final purposes. The good and proper application of each is therefore inspired and constrained by a superior, more final purpose.

You need to understand why you’re doing what you’re doing!

(The POAP is not exempt from the POAP.)

It’s quite simple! But, I can tell you from spending time in the forums and working with bright-eyed folks, it’s an oft-overlooked step in producing working code that both aligns with one’s guiding principles and the business’s actual goals. You need to understand why you’re doing what you’re doing!

In general, I’d suggest that we can test for adherence to the POAP by asking, in any given particular application of a principle, what superior purpose it serves and how it serves that purpose.

But, I’ll provide some examples of applying the POAP in future posts. So, please check back. Subscribe to be notified when I’ve posted follow-ups and examples and so forth. (Mailing list is pending.)

In the meantime, let me know what you think of the POAP in the comments below.

Update from 2021-05-26: Or maybe I won’t show you examples of the POAP. I’ve been busy. And, I have other things to write about. And, I think the POAP is actually pretty self-explanatory. Let me know if it’s not. I’m more than happy to followup questions from the comments with articles as-needed.

Back to index ...