Karmængine

Something else I need to write about. Developers who get worse over the years. How do you handle them?

Firstly I should define what I mean by ‘worse’. Well, essentially:

• Quality of code decreases
• Ability to estimate tasks decreases
• Attention to detail decreases
• Time distracted increases
• Work done fails testing more frequently
• Contribution during discussions decreases

I suppose the first step in handling this is to sit down with the developer, a senior developer, and a director and have a good old-fashioned discussion on these points. But this is not going to do much to solve the problems, it’s just going to result in the developer either bawling their eyes out, or agreeing firmly to try and improve matters.

So, more drastic action has to be taken.

Addressing a lack of code quality

A sit-down review with a high quality coder can help. Mistakes and vicious habits can be pointed out, as well as correct principals and other methods. This should be a personal tutoring session and take place every week for a couple of hours. Yes, this kicks eight hours out of our two-week sprint, but I consider that that’s peanuts compared to the damage being done. It’s only the start, though!

Helping with task estimation

Estimating tasks is supposed to be a personal thing – the developers should visualize the process of developing the solution, of testing, of documenting and preparation. They should total the hours they’re likely to spend on these aspects and that should be their estimation. But if the developer has trouble visualizing, or breaking a task into ‘actual things to do’, their estimate will be rubbish.

To help the developer turn the task into actual things to do, it is a matter of simply extending the discussion of the task (prior to estimation) to include or share opinions from others on how they would approach it.

If the developer still doesn’t understand enough about the process to be able to give an estimate in hours, then it’s a problem. It’s a bogus developer who should be asked to re-evaluate his employment in the company. They may require extensive training, but in the case I’m talking about, where the developer has steadily declined, it may be time to put his experience elsewhere, rather on the frontline.

What to do when attention to detail decreases

Details are important, especially in software development – the world in which many finicky users stalk around with magnifying glasses. And, I personally find that when a developer makes the effort and pays attention to small things, that he is giving himself a little golden place in my heart. Obversely, when the developer ‘doesn’t give a hoot’, no matter how good they are, I get a little bit clenchy in the fist region when I see him.

Attention to detail can be increased by embarrassing the developer. Aye, it’s true. Point out his mistakes (even though they may not be technically mistakes) during stand up meetings. Laugh about them, make jokes. Be light-hearted about it, not stern. He will laugh too but watch his cheeks go red. If this continues to happen he will knuckle-down, out of the basic human need to ‘fit in’.

Another good way to make a mockery of a developer is to not single him out. Make a joke to the team that some silly person -did-whatever- and how funny and troublesome it is. If he immediately owns up to being the cause, it is something very respectable.

Removing distractions

I am always of the school of people who don’t want to restrict workers at all in the office. Introducing ‘no browsing’ or ‘no music’ policies is insane, in my opinion. The real way to remove distractions is to make the developer understand that while he’s not working, he is overloading himself in the future, and, since scrum is all about the team, he is increasing pressure on the team.

An interesting way to do this is to speak with another developer, someone who you trust and who you’re friendly with. Tell him or her that you are going to make an example out of them after the stand-up meeting, but only as an example to the other developer. Then, after the stand-up meeting, question your friend about his forum chatting or flickr browsing during working hours. Then directly ask the team how much pressure they’re feeling right now, and if they really have time to waste on non-productive activities. If they all agree that they do have spare time, that’s your fault. It might be a chance to introduce a brainstorming or knowledge-sharing session for them. That would be better than seeing them mucking about on youtube all day.

I also hate checking up on people. Procedures can’t be measured, only results can. But checking up sometimes help. It helps sometimes to just go and look at the developer’s screen. Don’t say anything, just look. They will feel uncomfortable, but since you’re not really putting any pressure on them to ‘get back to work’, they will get a splash of guilt, rather than anger. Pat them on the shoulder when you walk away, too. This is a friendly gesture which means ‘you’re part of the team, I like you’. It is a little condescending, but I feel it’s the right approach.

Reducing test failure

Again, this is where humility comes into play. It’s usually like this: the developer works on his task, tests it on his local machine, commits his changes, and then doesn’t test on the development environment, or does a very limited check to see if the thing didn’t break after his commit. Then he goes to make coffee or unwind his brain from the task he’s finished.

Then someone tests his task and boom. Test failed.

The developer often takes an hour or more to be informed of his failure, then some time to begin working on it again, then time to find and fix the problem, and so on and so on, damaging the team’s performance. Test failed tickets are like a stab wound to the team. They can be fatal.

So – how to make sure the developer fully tests his own work before and after committing? Humility, yes. Embarrass him again. Count up the number of test failed tickets during the sprint and make the developer with most wear some silly t-shirt during the next sprint planning session. Be creative, but not cruel. Make him feel like the other developers are laughing at him. There’s only one direction he can take to resolving it – and that is to ensure he doesn’t have any test-failed tickets in future.

Increasing the developer’s contribution during discussions

There’s not a lot that can be done about this one, except directly asking during discussions for the developer’s opinion. Try to get him involved in the same way you’d try to get anyone involved in a conversation. Ask questions, talk about the things they worked on, and so on.

If someone starts falling asleep during the planning session for example, depending on how horribly mean you are, a sudden clap is quite entertaining for everyone else, and will wake them up.

It also helps a developer feel like a sturdy cog in the wheel if you praise them. And, when he feels like a contributing member, he will act as one.

In the end, it’s essential to remove the ‘dead wood’ from the team’s little bridge, and replace it either by employing someone different, or solving the problems causing the wood to rot. If you don’t, the whole thing can collapse.