It needs to be a sensible combination of all of the answers so far. In the end, when you're talking about a group of smart people (developers), you have to give them reasons why the behavior is important and give them enough control over how that behavior is implemented that they are invested in doing it right. Mandates from above are generally a loose with smart people, because if they have not agreed that the problem is a problem, then they are likely to spend more time working around the mandate than following the rule.
Here's a few of my tactics:
First, the team needs to agree on when to commit and what to commit. Absolutely essential is a build setup that makes sense, so that people aren't holding off just because they don't know where to put something. And a consensus on when/how often to check in. "don't break the build" is an obvious good rule, but how is that checked, and who gets told about it? Another baseline is "it's not done if it's not checked in".
Most developers I know are more than happy to check in code IF:
- The check in process is easy
- The synchronization process is easy (factoring in changes from other developers)
- Seeing changes and moving between versions is easy
One thing that I noticed recently was that checkins got more frequent and less painful when we lept forward to a new CM tool. Our team is pioneering Rational Team Concert having formerly used Clearcase. I don't mean to advertise tools, but the new (to me) wave of streaming checkins with lots of small, fast merges makes it way more enticing to checkin early and often.
Letting developers be in charge of eliminating CM pain generally increases the amount of checkin in that happens.
Adhering to Architecture - Not Writing Model Issues in Views and Controllers
I'm putting that in the general clump of "do the architecture correctly". I agree with whoever said peer reviews - peer pressure is great for this. One of the ways I generally see people come into the fold for best practices in this area is when their peers ask them why they did it the other way (the not so right way). Generally the "why" question will lead people down the path of realizing for themselves why they should have done it differently. When people have a well understood reason for the best practice, it's much easier to adhere to it.
Also, if there's some formality linking a person to a decision, then it can be easier to assign bugs in that area... so if a person is responsible for fixing bugs in an area of faulty design, the need to get something right before they can move on to something new and exciting can be a big motivator.
I'd start with clear coding standards and integrating a coding standard review in peer reviews. Hard coding is one of those things that can easily be a checkbox on a peer review agenda.
I'm afraid that this sort of thing is the one thing where I've seen it become the role of the team lead to enforce the rule. In teams I've run, we generally won't let someone move on until they've fixed the comments from a peer review of their code. And "no hard coding" is a frequent peer review comment.
With almost any best practice, I think you have to pick your battles. No team will become absolutely perfect. But you can keep an eye on your major pain points and start tackling them in clusters. I think it becomes the role of the leader to really know what is a pain point for the team vs. an annoying quirk of a particular individual.
If your team is missing out on doing a particular best practice, I think the first question must be "how much damage is this causing?" if the answer is "minimal", then it's probably not worth the time. Some best practices are most relevant to specific types of systems - while they are good overall, they may not be worth the battle for systems where the practice is not a frequent occurence or major part of the system.
If the answer to "how much damange?" is "ALOT!!!", then you can start building a case for showing the team that all this pain and suffering could be removed by fixing this one slacking point in best practices. Most people are happy to avoid pain and suffering and it changes the dialogue from "do this because I told you to", to a "we decided to do this because it's better".