Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I work as a kind of mixture of a Scrum Master and a team lead. In my team I have the problem that one of the members delivers bad quality. The code he produces is difficult to understand, difficult to maintain by anybody else than the guy himself. The solutions are more a "hack" (if not a botch) than a conceptual or elaborated work.

And what is worst: he doesn't see it. He thinks he is a quite good programmer, when all the other team members are constantly complaining about his code - when he's not there (which is not so difficult since the guy works remote most of the time). They all avoid to tell him what they think about his work because they don't want to offend or demotivate him.

What should I do?

  • Try to tell him what the others think in 1-to-1 meeting? But I don't find it right to say "the others are complaining" when the others are not there and don't bring up their examples.
  • Set up a team meeting and encourage the other members to tell what they think? But this feels like a tribunal to me. (And all against one is not fair.)
  • Something else?
share|improve this question

marked as duplicate by gnat, Kilian Foth, thorsten müller, jmo21, Bart van Ingen Schenau Apr 16 '13 at 13:43

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Obligatory question: can you describe your code review process? – user16764 Apr 16 '13 at 0:33
"I work as a kind of mixture of a Scrum Master and a team lead." - that's a bad idea, and makes it harder to find a solution. – Landei Apr 16 '13 at 7:33
Stop being afraid to hurt his precious feelings ! He's not your wife. You HAVE TO address this issue. It's part of your responsibility both as team leader and as SCRUM Master. Do it asap. And do it the right way. Not too harsh and not to soft. – Radu Murzea Apr 16 '13 at 19:56
@ user16764: We do peer review at the end of each story. It's far from perfect, because that's quite late but that's what the team accepts and can @Landei: I know that it's not ideal to combine team lead and scrum master in one person. But that's the way how "Scrum" was adopted so far by my company. – Juergen Apr 18 '13 at 21:44

9 Answers 9

Let me play the devil's avocate here.

Maybe all of your team, with the exception of that programmer, are the ones who are inferior, and he really is a brilliant programmer.

Imagine if, say, Linus Torvalds (let's pick a poster boy for accomplished programmer) for some reason fell into a situation where he is working in a team of moron programmers whose average IQ is 75. They would also not understand his code. "Nobody can maintain it but that guy himself! It is of bad quality!"

Nowhere in your question do I see the obvious complaint: that the code is incorrect, that it simply doesn't work. Those are the primary, objective indicators of bad quality. The rest are subjectives: hard to understand, maintain and so on. If the code does fail, why wouldn't you mention that? Are you by chance criticizing the fluffy subjectives because the code builds and holds up in execution?

Sometimes easy-to-understand code is wrong or inefficient, and making it right or efficient also makes it hard to understand. For instance, nothing makes concurrent code easier to understand than removing all the mutexes, semaphores and any code which deals with resolving obscure races, like re-evaluating states that might change and so on. Bubble sort is easier to understand than quick sort. A matrix multiplication is easier to understand than a fast Fourier transform. An H.264 encoder is harder to understand than one for motion JPEG.

Moreover usually code that really is hard to maintain in some objective sense is also that way to the person who wrote it. But in this case, you observe that nobody but that guy can maintain it. So in other words, someone can maintain it. Just not the rest of the team. So that guy has something the rest of the team doesn't: the ability to maintain that code. It's not like the code is has secret components: it's open to all of you to read. The excuse that he has an advantage because he wrote it is very thin, because the code does not make remote procedure calls to secret routines in his brain.

Without actually seeing the code from this person (and perhaps from the rest of the team, for the sake of comparison), there isn't any reason to believe that you are right, and that programmer is wrong rather than vice versa.

share|improve this answer
Well written code that a stupid team can understand is better for a project than its superfast hacked together counterparts. If the guy drops dead the project stops. Unacceptable! – Mvision Apr 16 '13 at 6:02
Op may imply that this guy's code is a mess (naming variables x1, x2, x34; zero-commenting; wild macro-ing) and working with it wastes anyone's time although capable of understanding it where well-written code can also be as fast as his but a LOT easier to deal with. – Marco A. Apr 16 '13 at 7:11
Could be. Without further clarifications, or seeing the code, it's anyone's guess. When someone tells us a story, we should not assume that his view is the unadorned truth of the situation. Either way though, be he a dunce or genius, that programmer does not fit well with the rest of the team. – Kaz Apr 16 '13 at 7:51
As I said in my answer - "1/2 of all programmers are below average". If Linus starts working with me, he will be told, just like all my team members, I expect his code to be able to be understood by a Graduate, and maintained by that graduate when he has a year of experience. For the work Linus is known for, it's fine to exclude 99% of programmers, most of us don't get the luxury of being that precious. Any idiot can hide behind complex, hard to understand code - A master will write simple easy to understand code. – mattnz Apr 16 '13 at 9:33
I really like @mattnz quote "I expect his code to be able to be understood by a graduate, and maintained by that graduate when he has a year of experience". This is exactly how it should be!! – Jimbo Apr 16 '13 at 10:03

At some point you have to be in charge. Code is done a certain way or it is done over. If he can't at least correct his mistakes, he has to be let go.

I'm trying not to overly simplify this. There is a difference between an inexperienced coder who makes mistakes but is willing to learn and someone who thinks they are always right and does not recognize constructive feedback. Let him know what is expected and that you are no longer willing to accept his hacks nor allow him to debate his practices.

Eventually, we all have to get with the program or move on.

share|improve this answer

You discuss fair - is it fair on the other team members to let poor quality code into the code base and make them deal with the consequences? Not dealing with it is incredibility unfair. However, letting them at him like a pack of wolves, not right either as @Southpaw said, its open ended, common and lots of info to help..........

One solution I have used is a proper, formal Code review, avoid an informal or non structured Code Review at all costs. Initially you may want to being in an outsider, experienced in formal code review, as a moderator. Yourself and no more than one other as code reviewers. Do not try to be a reviewer and moderator. Introduce reviews for all work (or at least evenly distribute what gets reviewed) and invite this person to be a reviewer. i.e. Do not target him. Once the team is comfortable with reviews you may find some of the formality can be dropped.

The reason I say formal review is that in this situation, an informal review can quickly turn into a bagging / demotivating witch hunt, and be counter productive. A formal review process completely removes the emotion from the review and focuses on the code under review, not the people. Where a team has great dynamics, less formal reviews can be very effective, so there is a place for them.

Also remember that (assuming normal distribution) - 1/2 of all programmers are below average, many in this industry cannot remember this basic high school math, which is surprising given we all think were pretty clever.......

share|improve this answer
This is all about the code review. You might even look at using a tool so that only reviewed code gets merged into your main branch. That way everyone has to be reviewed and everyone benefits, as well as the code. – glenatron Apr 16 '13 at 11:17

You, and the other members of the team, need to learn congruence. Congruence is the alignment between the internal and the external – between what is thought and felt and what is said and how it is said.

When you can speak congruently about the what's going on – taking into account yourself, the other person, and the situation – you will be able discuss it without blaming, shaming, threatening, cajoling, appeasing, or any of the other ways people attempt to deal with incongruence. And they will be able to listen.

An article by Gerald Weinberg called Beyond Blaming is a great place to start.

He also wrote a book called Managing Yourself and Others that is even better.

share|improve this answer
I will buy into this congruence buzzword, if this is the same Gerald Weinberg who wrote Psychology of Computer Programming. – Kaz Apr 16 '13 at 3:04
The very same. It's only a buzzword if buzzwords can survive for 3 decades or more. – Rein Henrichs Apr 16 '13 at 3:33
Gerald Weinberg is to the field of programming like, say, Gerald Sussman to actual programming. – Kaz Apr 16 '13 at 3:48
@Kaz I'm not sure what you're trying to say here. Jerry Weinberg is amazing. – Rein Henrichs Apr 16 '13 at 4:25

Ensure that each story, as part of the definition of done, includes a peer code review. Have an open and honest discussion between the coders for each story. If possible, have the developers review the code at the same time, same location.

During the code reviews not only focus on the elements that need correcting/ refactoring etc., but also highlight and explain the benefit of the patterns that are welcomed as best practice and expected within the team.

As your troublesome team member attends the code reviews of others, they will absorb the better practices of others and be aware of better approaches available.

share|improve this answer
How would you organize such a review session? Aa lot of code might be produced while working on a story. So reviewing all of that in one sessions will probably take very long. – Juergen Apr 18 '13 at 21:53
It would be task within the scope of the story, should be scheduled as the code is delivered to QA. You can either use a pull request or svn commit as the agenda. The review should be part peer review (these are the changes I, the developer, made so the team understand the new functionality) and part code review when during the review, constructive questioning on pattern choice and style are discussed. The value of knowledge transfer and dissemination of the agreed practices/ pattern is worth the time taken. The team will get faster reviews the more reviews are held. – abh Apr 19 '13 at 21:00

Review the code. If it's unnecessarily complex, suggest simplifications. If the variables are badly named, suggest better names. If the functions are too long, suggest blocks that should be extracted into separate functions. If the remote developer is not interested, make it clear that he is going to have to improve.

On the other hand, I have seen situations where a new programmer was taking an hour to writing ten lines of obviously correct code C++ STL calls in when the rest of the team was taking a day to write and debug fifty lines of nested loops. The team complained about the new programmer because they didn't want to be bothered learning the C++ STL.

Which of these scenarios is yours?

share|improve this answer
The first scenario is what I see in his code. I already tried what you suggest but he don_t seem to grab it. And Unfortunately I have too less time to always check and review the code on my own, – Juergen Apr 18 '13 at 21:59

Every story on a scrum model should be labeled new feature, rework, refactor. If the dude says I am done, then he can either rework on defects or refactor on code reviews. Hold the refactor for 2 code reviews and after that, the story should be owned by someone else to fix / close.

All other suggestions above hold good, but as a rule and to ensure that people understand that more than 2 code reviews and no movement on the story (still refactor) means that you are going to loose that ownership and frankly if you loose more than 2 stories, you have attributed to the loss of the project schedule and quality.

Use this data to reassign easier tasks and scale someone up/down.

share|improve this answer

Let the guy upvote you on this question, then he'll get it.

On a more serious note. Put some rules in order that count for everyone. Decide what those rules are as a team. Let everyone document their code properly.

Consider letting him do some pair programming.

share|improve this answer

This is a very open-ended question with a wide-ranging set of answers, and one that you should look within yourself introspectively before selecting an answer of your own. Decisions about dealing with co-workers is never as black-and-white as coding problems (and those are very far from black-and-white themselves).

Idealistically, the "best" way would be to be honest but constructive - explain your problems in the form of positive, helpful, constructive criticism with the intent (not just the illusion) of helping better their code. If you do not feel that they would consider you credibly as their senior or superior in coding practices, then have someone else do it - say, a manager or one of the most senior programmers (possibly the most senior member of the group of complaining team-members). Hopefully, if presented correctly, they will accept the advice humbly, better themselves, produce better code, and not have their feelings hurt all simultaneously.

Realistically, though, people hate criticism - a sad truth we all live with. Even the best of us can be biased and resistant to it. There are many books and articles on the subject and how to deal with this problem.

share|improve this answer
Programmers don't hate criticism. At least, not moreso than non-programmers. The best ones welcome it. – Rein Henrichs Apr 16 '13 at 1:36
I don't mean it as truly literal - it's just a general concept to keep in mind – Southpaw Hare Apr 16 '13 at 1:49

protected by maple_shaft Apr 16 '13 at 11:14

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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