There are several rules I must keep asking programmers to follow very often. They write code and, if it works, job is just done, for them. Most basic rules might be:

  • Commiting changes
  • Not writing Model issues in View or Controllers
  • Avoid hardcoding

Can you tell me about your experience? How do you manage this?

  • 2
    You should ask on programmers.stackexchange.com. Do you do code reviews? Do you have a code review tool like Crucible? I would recommend doing thorough code reviews and insisting on all issues being resolved before any other work is carried out.
    – Ondrej Tucny
    Commented Dec 28, 2010 at 12:29
  • 15
    You can try leaving horse's head on their bed that worked in Godfather.
    – Gaurav
    Commented Dec 28, 2010 at 14:08
  • 4
    I've had great success with high voltage. Your mileage may vary.
    – user131
    Commented Dec 28, 2010 at 14:34
  • 2
    @Tim: a rolled-up newspaper is more eco-friendly Commented Dec 28, 2010 at 17:10
  • @Steven, I guess it would be. First you re-purpose the newspaper, then re-cycle it. I suppose there is an art to green intimidation.
    – user131
    Commented Dec 29, 2010 at 15:03

17 Answers 17


All knowledge workers need to be challenged to do quality work. Quality will suffer if they feel arbitrary time constraints are placed upon them. Why not just make things that are "good enough" when everyone is concerned with fulfilling the specifications and meeting the deadlines?

Your list of complaints are symptoms of a company that only rewards meeting short-term objectives and has no desire to emphasis high quality. Are you running a five-star hotel or a truck stop?

  • 1
    +1 for pointing out this is a cultural issue and needs to be addressed from a motivation standpoint. Commented Dec 28, 2010 at 18:41
  • it is both a company cultural issue as alluded to by JeffO. but sometimes that culture gets cooked up from the bottom up when coders and developers have no vision for quality code or for the need of it. when they were in Computer Science school, their professors should have slapped them on the sides of their head a few times. Commented Jun 15, 2016 at 19:02
  • @robertbristow-johnson - Good point.
    – JeffO
    Commented Jun 16, 2016 at 21:05

To be able to follow the basic rules, they need to know what the rules are and they need to agree with them.

The way to handle this is to jointly create a coding guideline document which everyone can agree with. Don't try forcing this on them, it will backfire if you do.

So get the team together and start working on a common definition of your basic rules!

Do it as a workshop where all voices are heard. Timebox it to avoid endless discussions. You are trying to bringing several minds together, so you may want to set the stage with a positive note that you all should be respectful and keep an open mind (code writing is personal...).

These guidelines should be alive changed whenever the team feels there is something that should be added or clarified.

  • 2
    Though I agree, I also disagree with "Don't try forcing this on them, it will backfire if you do." - When it's all said and done, whether or not someone agrees on the basic rules is irrelevant. The boss makes the rules, follow them or find another job. We're not so special that the employer-employee relationship doesn't apply. Commented Dec 30, 2010 at 21:19

What is your role? If you are just another developer with a particularly strong interest in code quality, you probably don't have the authority to get them to listen to you, and maybe you should bubble up these ideas to management to establish code standards that should/must be followed. If you are a manager/team lead/architect whatever and you do have some authority, then you can establish those practices yourself. Institute a standards document and a code review process to weed these things out.

It is not going to be a magic switch that you can turn on; it will be a slow process and will never been 100%. That's been my experience anyways.

  • 1
    Agree. This is a political issue, not a technical.
    – user1249
    Commented Dec 28, 2010 at 14:48
  • And any code standards would have to be agreed upon at least partially by the group. Tools like StyleCop help a great deal.
    – Job
    Commented Dec 28, 2010 at 17:03
  • My boss is trying to push his "code quality", but it just doesnt take off, because the people don't believe in it. having power is not always the answer.
    – IAdapter
    Commented Jan 9, 2011 at 17:30
  • @0101 Very true. The power helps to push the message. The message has to be crafted so that it will be accepted and followed. Commented Jan 10, 2011 at 14:37

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:

Committing Changes:

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.

Avoid Hardcoding

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.

In general

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".

  • Long comment, but your approach is awesome. In order to get people to adhere to these guidelines, they do need to believe that it's a benefit. I'd be interested to hear some examples of how this has worked for your team.
    – jmort253
    Commented Jan 9, 2011 at 21:28
  • My favorite example is consistent test environment setup. I didn't HAVE to enforce a Right Way. I had a guy in charge of the install document. I said - "it's all you- you can do whatever it takes to make an install mechanism that ensures consistent install - everyone is empowered to bug you if the install is messed up". In less than a month we had a solid tool and a very short document. And the tool was installed as a short cut on every desktop. I didn't need enforcement, proper installation was already the path of least resistance. Now our goal is to remove the shortcut, making it automated. Commented Jan 10, 2011 at 20:57

Code review. Accept only well written code that has no errors.

  • 3
    That is not a solution for the underlying problem. Don't waste time with code reviews, when you could fix the root-cause problem instead. Commented Dec 28, 2010 at 15:57
  • If you can force them to rework stuff again and again, their inherent laziness will get them to start to conform over time. Commented Dec 30, 2010 at 21:05
  • Agreed, people just need to be responsible and do their work without being told. Code review after each and every change is a massive waste of time.
    – jmort253
    Commented Jan 9, 2011 at 21:32

At least :

  • Make it easier for them to follow codelines (Tools like resharper, StyleCop) If it is easy they are more likely to adopt.

Besides that choose what works based on your organisation, the developers and your role within the team.

  • Let them do bug fixes and change request regularly
  • Pair program with an experienced developer
  • Code reviews in a constructive manner
  • Code walkthroughs
  • Start training, use books like Code Complete and The pragmatic programmer.

My role is Manager, but as a small team I do develop and I rather prefer to manage as a coach.

Electrodes in the chair connected to a code parser has already been pointed out, but programmers don't seem to be afraid. Firing does not sound as a good approach, as that means loosing worthy assets.

I'll take a look to all those tools and I remain open to any other you tell me.

  • 3
    If your assets are so worthy, maybe these issues aren't so important? You have to pick and choose your battles some times.
    – JeffO
    Commented Dec 28, 2010 at 22:00
  • My question is about improving what I have, that is more difficult but effective than search&replace Commented Dec 29, 2010 at 8:56
  • Firing people who will not follow coding rules is NOT losing good assets, it's getting rid of deadwood.
    – HLGEM
    Commented Dec 30, 2010 at 20:55
  • @HLGEM - Unless the person who doesn't follow the rules just happens to be a code ninja who can solve any problem in the organization. Dr. House doesn't follow the rules, but if the hospital fired him, there would be lots of fictional people who would die. en.wikipedia.org/wiki/Gregory_House
    – jmort253
    Commented Jan 9, 2011 at 21:31

There are 3 ways by which we address this issue:

  1. Static Analysis of the source code to check for issues with coding convention. Use tools like cppcheck and those from grammatech. Wikipedia has a good list: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis. Typically most source control systems will have hooks by which you can check for such issues directly during the check-in. For CVS hooks look into this link: http://goo.gl/F1gd2. Failure to comply means a failed check-in, and more than 3 failures mean that the developer has to explain himself/herself to the team.

  2. During the coding process itself flag issues to the developer. Having custom scripts that are integrated with the IDE of your choice is a cool way to do this. Check this link out: http://goo.gl/MM6c4

  3. Follow agile processes and make sure that code review is part of the sprint

  • 1
    +1, I have commit hooks that runs anything that has been modified through splint (and several other lints) as well as tools to make sure I'm not including headers needlessly, plus making sure indentation is tabs not spaces, etc.
    – user131
    Commented Dec 28, 2010 at 14:36
  • Technical solutions are not going to help if the developers are not obliged to use them. Commented Dec 28, 2010 at 22:29

Here's my 3-step plan:

  1. Fire the programmers
  2. Hire some Software Engineers
  3. ...
  4. Profit!


In all seriousness, if they don't believe in doing anything but writing code you need a more well-rounded team. A programmer where I worked used different directories on the computer as her CM. We fought with their programmer for almost a year (as changes would introduce bugs as they copied and pasted old code). We eventually just fired them.

  1. Do point out to them, when they violate basic rules.
  2. Wait for them to produce bugs they just can't track down or to be confronted with feature request they just can't implement due to their inflexible code.
  3. Remind them of what you had said earlier.
  4. Let them drown in their own shit for a while.
  5. Take the time to refactor the code in question, isolate the bugs / provide infrasturcutre to plug in new functionality. Take some time to explain what you did.

Alternatively, the most cruel but very persuasive thing to do is let them maintain an extremely poorly written codebase, given a tight schedule. :D
And then, for a change, let them maintain a well written codebase, given a tight schedule.

Generally, the unwillingness to adapt certain standards means a lack of experience in team work.

In the end people only learn from mistakes. NEVER fix problems, that are based on someone else's stubbornness. If it is really vital for the project (i.e. your company will be sued if you you don't deliver within N days), then put them off the project first.

  • I love this. Great recipe for making someone hate you. ;) Commented Dec 28, 2010 at 18:33
  • @Roman Zenka: Possibly, yes. But if the choice is between being hated and being frustrated, because you're having an NNPP on the team, I prefer the first option ;)
    – back2dos
    Commented Dec 28, 2010 at 18:49
  • At this point, they need to be put off the payroll.
    – JeffO
    Commented Dec 28, 2010 at 21:59
  • I've actually worked on that! And they dont hate me. The conclusion is, everyone is comfy in his own shit. And that makes this task so difficult. Commented Dec 31, 2010 at 9:51

I think you programmer won't change their attitude towards these issues you've mentioned until they realize that those things will lead to a benefit or advantage for them. Try to explain them why you want them to do these things. Even better, let them experience the advantages.


Hire one professional Software Engineer. And then fire weakest. Then slowly replace those who can't adopt. Having such people sometimes bring more harm than profit in long term.

Main idea here, that professional will start doing most job, and firing others will not reduce valuable human resource.

  • 1
    This is a great way to make up for a lack of leadership skills and ability to mentor less experienced individuals. If your persuasion skills suck, just start firing all the people who disagree with you.
    – jmort253
    Commented Jan 9, 2011 at 21:22
  • @jmort253, If i have a chance, I would fire every programmer who is not committing to version control on regular basis. From author words, I get that ALL programmers are very inexperienced, and don't want to learn and improve themselves. Commented Jan 14, 2011 at 11:57

It's a little gross, but I left Code Complete in the bathroom for a few months. Not sure it was effective, but it seemed like a good idea at the time.


So what are the consequences for not following the rules and rewards for following the rules? If the answer is the same--nothing--good luck getting any traction. I suggest a tiered approach. First get them together and discuss whether they buy into the rules. The next step is to include them in code reviews. You can also try carrots and sticks. Something like anyone who leaves a file checked out overnight has to bring donuts to the next weekly meeting. A carrot could be anyone who follows the rules for a whole month gets a weekend in Vegas. For two.

Or fire the worst offender and let the rest sweat it out.

  • Eeep! You have a sole-checkout type of VCS? Get with the century, man! Commented Dec 30, 2010 at 21:07

Make them suffer the consecuences you want to avoid by using those rules, it is the only way they are really going to understand why you are asking, e.g.: make a small controlled mess that they have to correct.


If this crew is really having trouble checking in changes, adhering to separation of concerns and not hard-coding magic constants then I would fire the whole crew and replace them with real programmers1 that actually care about their craft as soon as possible. Be that one at a time or en masse I couldn't say but these jokers have got to go.

The sort of coding that you are describing is suitable for throw-away, one-use-only scripts. It is not how one builds a real application. If they are getting paid as professional programmers, then it is their job to know this sort of thing.

1 This is often used as a joke term for imaginary people that write their code directly in binary or something equally ridiculous. Here, I'm not joking. I'm a fairly rookie programmer and I wouldn't need to be told these things because I care about my craft. These are not real programmers that you are dealing with.

  • I agree with everything except the firing part. Good luck dropping every other critical task you're working on as a manager, including meeting deadlines and customer milestones, to replace your entire experienced staff with people who can comment code but who have zero domain knowledge.
    – jmort253
    Commented Jan 9, 2011 at 21:24

A manager's job is not to be the friend of the employee, sometimes you have to be the bad guy. Enforcing coding standards and commits, refusal to follow proscibed architecture, failure to use prescribed tools etc are the times when you have to be unpopular.

Express the policies clearly. Do formal code reviews and check to see if policies are followed. Do not permit them to move to another task until all issues from code review are adjudicated.

If the policy is concerning not commiting code, this calls for a written warning if they cannot do it when they are asked to do so. If they are not committing code, as far as you are concerned they haven't written any.

If they don't improve after being given a reasonable chance to improve, fire them. Unprofessional developers are a drag on your team no matter what kind of code they write. They are affecting others with their lack of professionalism and it is not to be tolerated. They are not good people to retain in any event. Good developers commit their code, good developers follow architectural decisions even if they don't agree with them and good developers don't hard code. You won't be missing anything except headaches by getting rid of cowboy coders.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.