How do you ensure code quality when having a weaker programmer on your project?

Question

In an ideal world, each new joiner is expected to be trained with the practices and standards applied on the project. Happens that the ideal world is far from reality. When project starts getting off track, is not rare to have more manpower added on it, which is doomed to failure.

Right now, the project is lacking people and a new developer has joined the team. His programming background is known for his low quality. On his first experiences on the team, he demonstrated a lack of a clarity on what he was doing, and if he keeps work like this he'll increase the project's technical debt.

Right now, the first mitigation - which is already proven valid - is the implementation of code review. However, it takes time and dedication from both people involved, which would impact the project plan.

How should this situation be dealt with?

Answer 1

It's great to hear that Code Reviews went smoothly and you are seeing results soon, you have seen it's effective and that means the junior programmer is keen to learn (All good stuff)

Few things I would like to suggest which can be done at your end

1. Good code samples from existing code base - You probably have some star quality code in your existing code base(with expected formatting/styling, naming conventions, well designed & reviewed) . Point this out to your junior developer so he can gauge the benchmark he has to meet.
2. Static Code Analysis - Invest some time to identify a correct static analysis tool for your project(If you don't have one already). There are tools which help to correct coding style, find tech defects such as cyclomatic complexity & security issues. This could however take time. But a static analysis tool will reduce overhead at code review sessions. Will be useful for the entire team. ( Few examples from java world - checkstyle,Findbugs)
3. Peer reviews - Can you find at least one more developer at his level? (not skill level but in team structure) If so, you can introduce peer reviews between all junior members before the code is reviewed by a senior. This way there will be less overhead for the senior reviewer. If possible, avoid doing peer reviews for the developer in question only. That might create negative team dynamics. Also it'll be a good learning experience for the whole team.
4. Code review by Senior/Lead developer - With above steps implemented before reaching this point the overhead will be less.

To summarise above,

• First we clarify expectations
• Automate with static code analysis
• Reduce overhead & increase learning opportunities
• Ensure quality is met with a final review

Answer 2

Do Pair Programming. I often find that Code Reviews tend to demoralize people, because you criticize (potentially a lot of) their completed work. Even if you are good at giving feedback and the other one is good at taking it, this will be an issue.

In Pair Programming, on the other hand, you start a task together from scratch. Let him take the lead, listen to how he want's to solve the problem, and make suggestions about how to do it better. Do this for 1 hour or 2, at most. Then he should continue on his own for a while. Afterwards, you can do a code review. You will find that there is much less to criticize this way. And he will feel encouraged, because of that and because of the cooperation. Repeat this ritual and change pairs. After a while, he'll get your values and improve. And in the end, maybe you can learn something from him, too ;)

Answer 3

I would suggest, the new member be involved in testing of existing module rather than coding as this would introduce the new members in existing coding practices and standard. Once the new members has a basic idea of the coding practices, it would be best to introduce the new programmer in programming reports or basic forms.

Answer 4

If you don't have much time (and you do follow the advices mentioned above) then I would book a meeting with him and personally go with him through his code and tell him what you don't like or even better agree on a plan on how to structure/write code on your projects.

This way you can get mutual benefits that can be effective immediately.

Answer 5

I like other answers as they're trying to mitigate your immediate situation and work around your problem.

To expand on those answers if you are Manager / PM and have some authority over what is being done on the project, in my opinion you should seriously assess whether it's worth to keep programmer that is far from your standards of hiring.

Taking into aside problem of being forced to incorporate this person on the team without proper recruitment, possible negative implications on your team of current situation are:

• Brook's law already mentioned by you
• Lower overall team productivity due to need of "baby sitting" under performing developer
• Morale degradation among other team members and higher attrition risk due to the fact that great engineers want to work with great engineers. Accepting person with weak performance takes away sense of eliteness from your team and makes it less compelling for engineers to stay on the team.

As PM / Manager you should start discussion and try to raise awareness of the fact how bad for team dynamics is tolerance of weak performers. Also, surprisingly many Managers in organizations still treat managing knowledge workers like they would be working on factory plant and not on creative work.

Peopleware is unfortunately still valid and more relevant than ever.