Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Dec 28 '10 at 13:56

This question came from our site for professional and enthusiast programmers.

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 Dec 28 '10 at 12:29
14  
You can try leaving horse's head on their bed that worked in Godfather. –  Gaurav Dec 28 '10 at 14:08
4  
I've had great success with high voltage. Your mileage may vary. –  Tim Post Dec 28 '10 at 14:34
2  
@Tim: a rolled-up newspaper is more eco-friendly –  Steven A. Lowe Dec 28 '10 at 17:10
show 1 more comment

17 Answers 17

up vote 4 down vote accepted

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?

share|improve this answer
1  
+1 for pointing out this is a cultural issue and needs to be addressed from a motivation standpoint. –  Alex Feinman Dec 28 '10 at 18:41
add comment

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.

share|improve this answer
show 1 more comment

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.

share|improve this answer
show 4 more comments

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

share|improve this answer
show 2 more comments

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

share|improve this answer
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. –  Martin Wickman Dec 28 '10 at 15:57
show 2 more comments

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.
share|improve this answer
add comment

Thanks for the answers. I just cannot vote up or re-comment as my reputation is too low here.

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.

share|improve this answer
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 Dec 28 '10 at 22:00
show 3 more comments

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

share|improve this answer
show 2 more comments

Here's my 3-step plan:

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

:D

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.

share|improve this answer
add comment
  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.

share|improve this answer
show 4 more comments

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.

share|improve this answer
add comment

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.

share|improve this answer
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 Jan 9 '11 at 21:22
show 1 more comment

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.

share|improve this answer
add comment

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.

share|improve this answer
show 1 more comment

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.

share|improve this answer
add comment

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.

share|improve this answer
show 1 more comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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