What do you do with a developer who does not test his code? [closed]

Answer 1

It seems that people have come up with a lot of imaginative and devious answers to this problem. But the fact is that this isn't a game. Devising elaborate peer pressure systems to "name and shame" him is not going to get to the root of the problem, ie. why is he not writing tests?

I think you should be direct. I know you say that you've talked to him, but have you tried to find out why he isn't writing tests? Clearly at this point he knows that he should be, so surely there must be some reason why he isn't doing what he's been told to do. Is it laziness? Procrastination? Programmers are famous for their egos and strong opinions - perhaps he's convinced for some reason that testing is a waste of time, or that his code is always perfect and doesn't need testing. If he's an immature programmer, he might not fully understand the implications of his actions. If he's "too mature" he might be too set in his ways. Whatever the reason, address it.

If it does come down to a matter of opinion, you need to make him understand that he needs to set his own personal opinion aside and just follow the rules. Make it clear that if he can't be trusted to follow the rules then he will be replaced. If he still doesn't, do just that.

One last thing - document all of your discussions along with any problems that occur as a result of his changes. If it comes to the worst you may be forced to justify your decisions, in which case, having documentary evidence will surely be invaluable.

Answer 2

Using Cruise Control or a similar tool, you can make checkins automatically trigger a build and unit tests. You would still need to ensure that there are unit tests for any new functionality he adds, which you can do by looking at his checkins. However, this is a human problem, so a technical solution can only go so far.

Answer 3

If you can do code reviews -- that's a perfect place to catch it.

We require reviews prior to merging to iteration trunk, so typically everything is caught then.

Answer 4

Make it part of his Annual Review objectives. If he doesn't achieve it, no pay rise.

Sometimes though you do just have to accept that someone is just not right for your team/environment, it should be a last resort and can be tough to handle but if you have exhausted all other options it may be the best thing in the long run.

Answer 5

Here are some ideas from a sea shanty.

Intro
   What shall we do with a drunken sailor, (3×)
   Early in the morning?
Chorus
   Wey–hey and up she rises, (3×)
   Early in the morning!
Verses
   Stick him in a bag and beat him senseless, (3×)
   Early in the morning!
   Put him in the longboat till he’s sober, (3×)
   Early in the morning!

etc. Replace "drunken sailor" with a "sloppy developer".

Answer 6

You could put together a report with errors found in the code with the name of the programmer that was responsible for that piece of software.

If he's a reasonable person, discuss the report with him.

If he cares for his "reputation" publish the report regularly and make it available to all his peers.

If he only listens to the "authority", do the report and escalate the issue to his manager.

Anyway, I've seen often that when people are made aware of how bad they seem from outside, they change their behaviour.

Hey this reminds me of something I read on xkcd :)