Challenges of code review with remote team

Question

My entire team works from a different geographical location and I am the only programmer working remotely. I often find it quite difficult to have my code reviewed, as people take very long time to give their comments (usually they are genuinely busy with high priority work and I work mostly only on low priority projects/task ) .The company's policy dictates that it's not possible for me to checkin the code before the reviewer approves it. I usually start my projects with great interest but end up stuck in this situation quite often and it's very frustrating.

Also since I am not that assertive, I don't reach out to people and hold them responsible to review in fear of offending them. People do provide quality comments at times, but it completely depends on the person's bandwidth. What should I do in this situation to make team members accountable ? Should I talk to my boss about this problem? Do you think it would backfire ?

Answer 1

Just email them on a regular basis asking for an update on the review you asked them for. I find once a week reminders of this sort are generally often enough to make people get the work done without annoying them.

Answer 2

Ask your boss if someone takes times for the period files are waiting to be reviewed. Once this parameter will be monitored, people will treat it more seriously....

It is not your job to make the reviewer do his job. that's your team leader job (or his boss if he is the reviewer).

Just make sure you have enough at your hand to keep working while waiting for reviews so it won't reflect as much on your performance.

Answer 3

Should I talk to my boss about this problem?

Yes - it's his job to make sure you're able to do your job. That's what managers do.

While an occasional gentle notification to others to do the reviews is a normal part of everyday interaction, if it's a chronic problem because of their task priorities it's not your job to be their task manager. The manager needs to be aware of this situation so he/she can make sure the priorities among the tasks are correct.

Answer 4

I would have your team set up a shared calendar and have appointments for when you plan to conduct code reviews. I would suggest doing this as an entire team, not just for your sake. That way, if your appointments keep being denied or overlooked, then the upper management has visibility to it.

It's all about making your issue visible and if management cares then something will be done about it. If they don't know that there's a problem, there's nothing they can do to fix it.

Answer 5

I am in exact same situation: the sole developer on my team working remotely from a different location, and similar policy for obligatory code reviews before check-ins.

First of all, consider if remoteness is even a factor in this. If your work is truly low-priority compared to other stuff, then maybe what you see is quite normal. I'm not sure what you mean by "very long time" - hours? days? - so it's hard to be more specific.

Also keep in mind that no-one stops you from working on other issues while one is being peer reviewed (unless they are so closely dependent). If you use a source control system with "shelveset" functionality or similar, use that to switch back and forth between various things quickly. If you don't have that luxury, just have several copies of code checked out into different directories, and use them to work in parallel.

If your work is clearly hampered by lack of reviews (i.e. you find you're spending a lot of time doing literally nothing waiting for a CR), then you should talk to your manager about the problem in general (i.e. no finger pointing) first. Most likely, if the issue is objective, they'll relay your concerns to the rest of the team in such a way that no-one feels singled out.

Answer 6

Can you set up a separate code branch just for your work? Then you can check it in on your branch and merge the code to the main branch after it has been reviewed. This also creates a handy paper trail so you can point out (or even generate automatic alerts) when some code has been sitting in somebody's "in" box for a few days.

Answer 7

It's perfectly acceptable to bring these sorts of problems to your boss. Let your boss know that you need some guidance.

You should handle this task like you should any other task on a project. You should establish a time line with specific milestones and hold yourself (and your coworkers) to them.

When you establish your project plan and milestone time line, Send the person who is reviewing your code an overview of your milestones with dates that you'll be ready for review, and ask them when they think they can have the review done. Once they give you a date, you now have the power to follow up with them later.

"Hey Joe, thanks for taking the time to review my code, you said last Monday that you would have the code review done tomorrow, how's it going? Is there anything I can do to help?"

If Joe doesn't come through with the dates he sets for himself, you can record that in your project plan and have nice documentation for your boss to review. Since you have some extra time to fill waiting for code review, use it to better plan your project.

Answer 8

G'day,

Get your boss to fit time into the schedule of the team for code reviews. Maybe have code reviews one part of people's objectives, i.e. so many reviews per week or month?

To assist this maybe put together reasons for why the reviews make good business sense. You're lucky in that if the company has mandated reviews, then they understand the benefits already to a certain extent. That is if they are actually performing the reviews! But does your boss understand the benefits of actually performing code reviews? Or is it something the company says they do so that they can get a "tick in the box" to achieve a certain level in the CMM?

You might like to head over to the SmartBear site. They have some great resources there regarding code reviews.

BTW Is there a reciprocal in that do you review the changes of other team members as well? Timely responses on your part will help when you're trying to convince others of your need for review. Actually, do they actually perform reviews? Or do they just do a quick click to confirm that they've reviewed it and then check it in? Whether it's reviews of your changes versus reviews of their own changes they're going to need time to do them no matter what!

Working in a reactive rather than responsive team is very frustrating but surely they can't all be reacting to the latest crisis all the time. Although, there are plenty of of people who thrive on crises, many of them there own making! Have a read of the excellent RandsInRepose article "The Crisis and the Creative" which covers this "crisis" topic. (-:

HTH

cheers,