I recently read http://simpleprogrammer.com/2013/02/17/principles-are-timeless-best-practices-are-fads/ and it resonated with me. I find the more experienced programmers/architects go against current best practices and their excuse is some best practices don't work with their problem domain. For example, I have just started to work for a new company as a programmer and my architect writes his nhibernate queries in the UI layer instead of writing it in a separate layer. A part of me shrieks knowing this because it sort of goes against everything I have been reading on the internet for the past 5 years but I'm willing enough to try this approach and weigh the pro's and con's. Who knows, maybe he's right. I do find him as a very component programmer.
What separates a principle from a best practice (if anything)? How can you distinguish between the two, and how can you determine when it's appropriate to ignore either?
Best Answer
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".