Don’t think of it as principles vs best practices. In the process of writing my book on MVVM (I would say it was a shameless plug but it’s not out yet), I’ve come up with an analogy. Just like in art there were various movements throughout the ages, there are certain movements within software engineering. Just like you can identify a Gothic Cathedral via the flying buttresses and rose windows or a impressionist painting via its visible brushstrokes and open composition, so you can identify code that follows a certain software movement by looking for certain elements.

The MVVM movement has the View Model as its centerpiece with minimal code behind, functions encapsulated in commands, and decoupled messaging via an event aggregator. There is a beauty to the way these components are structured.

Those who follow Domain Driven Design create rich domain objects with persistence ignorance and logic embedded in the core of the objects.

CQRS proponents separate their domain models into a Query and Command model also referred to as a Read Model and a Write model. They like to use asynchronous calls via a message bus that updates the transactional store and the query store at the same time. And prefer a concept called eventual consistency.

The “best practices” of these movements aren’t globally applicable, but more or less attributes that are consistent with the movement. As new movements rise to dominance and old movements fade, they won’t be as prominent but that doesn’t mean the techniques of one movement won’t be useful with a subsequent one.

So What’s a Principle

Principles, like the article said, are globally applicable no matter what movement. Think of Uncle Bob’s SOLID principles. Or the Gang of Four’s Composition over Inheritance. These principles are applicable almost anywhere. Almost being the keyword.

Naturally, you can’t apply OO principles to Functional Programming. Well you can but they take on different forms. And once you have enough experience, you’ll know when a principle doesn’t apply. (You’ll know if you have enough experience if you don’t have to ask “Does it apply here” you’ll just know that it doesn’t look at the Dreyfus Model of Skill Acquisition at the Expert level, you don’t need the principles…they’re there but you don’t rely on them for decision making).

In the same way, once you have achieved expertise using a certain approach or style of programming, you start adding your own touch to that style. For example, I and a few other MVVM pioneers simultaneously and independently “discovered” the DelegateCommand pattern (and we all called it the same thing except Josh Smith who called his RelayCommand which is practically a synonym for Delegate).

In Summary

Principles are guidance for less experienced developers to help them make decisions via rules.

“Best practices” or Code Styles are approaches to development that provide consistency and familiarity for those who follow that Style

You’ll know when it’s appropriate to ignore each when you “know without knowing”.

What separates a principle from a best practice (if anything)?

The practice will usually be specific and concrete where examples from the article would include source control, unit testing, continuous integration, and other ideas that while the concept may be abstract, there are specific tools that could be used to demonstrate this is being used. For example, Subversion can be used for source control, nUnit for unit testing, Cruise Control.Net for continuous integration.

A principle on the other hand, would be more nebulous and thus not as tangible. The Agile Manifesto that lists these four ideas:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Thus, while one can take a specific example and look at whether these are being applied, there isn’t quite the tool to pull out to show, “Hey, we have working software over comprehensive documentation because we use X!” whereas the practices I noted above have tools that could be a litmus test.

How can you distinguish between the two, and how can you determine
when it’s appropriate to ignore either?

To my mind it is a level of detail. How specific does one want to get in applying an idea? At a high level there are principles and at a lower level there are practices.

As for when it is appropriate to ignore either, this is where you have to look on a case by case basis. For example, if I’m writing a script that will be used to generate some test data that I’ll probably use once, is it really worthwhile for me to spend hours planning it, building unit tests and applying a lot of extra overhead when what I could do is spend the half hour writing the script, run it and then commit my data when I’m done. This focuses a bit more on practices as those are easier to see where it is worth applying things since sometimes on small things, it may not be worthwhile to set up various practices that would be useful in other environments. Principles can be a bit harder to give a specific example.

How to Win Friends and Influence People is referenced in the article as having principles and here is something to consider in taking the ways to win people to your way of thinking:

Twelve Ways to Win People to Your Way of Thinking

1. The only way to get the best of an argument is to avoid it.
2. Show respect for the other person’s opinions. Never say “You’re Wrong.”
3. If you’re wrong, admit it quickly and emphatically.
4. Begin in a friendly way.
5. Start with questions to which the other person will answer yes.
6. Let the other person do a great deal of the talking.
7. Let the other person feel the idea is his or hers.
8. Try honestly to see things from the other person’s point of view.
9. Be sympathetic with the other person’s ideas and desires.
10. Appeal to the nobler motives.
11. Dramatize your ideas.
12. Throw down a challenge.

While this is a good list, it is worth noting that some ideas here can be a bit conflicting. For example, is there a friendly way to throw down a challenge? Perhaps there are friendlier ways but in trying to get someone to rise to a challenge there is something to be said for getting the person to stretch themselves. There is another set of ideas in the book that may be worth reviewing here too:

Be a Leader: How to Change People Without Giving Offense or Arousing
Resentment

1. Begin with praise and honest appreciation.
2. Call attention to people’s mistakes indirectly.
3. Talk about your own mistakes before criticizing the other person.
4. Ask questions instead of giving direct orders.
5. Let the other person save face.
6. Praise every improvement.
7. Give the other person a fine reputation to live up to.
8. Use encouragement. Make the fault seem easy to correct.
9. Make the other person happy about doing what you suggest.

Notice how some of these are similar. Number 7, “Give the other person a fine reputation to live up to,” is similar to number 12 in the first list, “Throw down a challenge,” which may demonstrate a principle about how most people have an inner fighting instinct that can be used at times. Similarly, notice how the number 3 of each list is about admitting one’s mistakes that may be about a principle around humility.