Managing a Remote Development Team

A friend of mine called the other day and was asking some questions about managing a development team that is separated by several time zones. I consider myself a thoughtful person, but not very quick, so the answer I provided was off the mark and not very insightful. Now that I have had a few days to ponder my answer, I believe that I now have something valuable to share.

To make my advice digestible I will break down my methods into many sections, each detailing one piece of the puzzle. I am providing them in the order that they should be implemented, because it is useless to put the cart before the horse. None of these sections is non-important, and with perhaps a few suggestions I strongly recommend implementing them all.

Before I begin to iterate my pearls of wisdom I do ask the reader to comment on what I will say here. There is always room for improvement, and I am always looking for suggestions on how to improve my process.

Pearl 1: Employ an issue tracking system.

I you don't use Jira, Bugzilla, or some other tool to track what is being worked on, then you are either headed in the wrong direction. I don't care if you have a team of 3, 30, or 300, you need to keep track of everything. My personal preference is Jira, for reasons you will see in the throughout this article, and I strongly suggest spending a little green to get it. Jira is dirt cheap for what they provide and in my opinion will provide at least a 100% return the very first year you use it. The reason for an issue tracking system is (1) it provides managers with insight as to what it being worked on, and (2) provides documentation on the work that was done. Ideally an issue will take no more than a day or two to complete, but I wouldn't get too hung up on that, the important part is to just keep track of what you are doing.

Pearl 2: Version control your code base.

No excuses, get that code into a good version control solution. Subversion is a great choice and has really good tool support, making it perhaps the best solution out there. If you use CVS, get rid of it, it lacks atomic commits, and atomic commits are very important. If you don't know what an atomic commit is, then find out. It is important to really understand how to use your version control system, and what the best practices are. You should always create rules around how to use your version control system, and my number one rule it to include the issue key from the issue tracking system with every commit. You must be able to take any line of code and trace it back to a task and the developer that wrote it.

Pearl 3: Define some coding standards

You don't need to write a book, but you must have some guidelines. Determine what is important and make a standard. For my team I require no tabs in source code, no cuddled elses, javadocs for every class declaration and method, expressive variable names, and more. If you are writing code in Java you should employ Checkstyle. Checkstyle is a tool that takes a set of rules and verifies that the code is in compliance. i recommend starting with one of the rules files that ship with Checkstyle, then tweak it ti fit your style. Checkstyle is integrated with IDE's and build tools, so your developers will have no excuses for not following the rules. Note that it is not so important to have good rules, just as long as you have some rules.

Pearl 4: Code review everything

There are so many benefits to performing code reviews; verifying compliance with standards, cross-training, less bugs, and simply better code. The problem with doing reviews is that it can be difficult to discipline your developers into performing them, and even if they are performed there is often no evidence that they occurred. This is where I need to recommend another tool, Crucible and its sister product FishEye. FishEye is a web application that allows you to easily search and browse your source code repository. It is an extremely useful tool in its own right, and the larger and older your code base, the more valuable it becomes for visualizing code changes and searching for reusable code. Crucible is a code review tool that uses FishEye's remote APIs to make committed code available for review. Crucible allows a moderator to kick off reviews and manages the overall process or performing the review. And most important it saves all of the comments from the review, providing additional documentation on the change that was made. There is also an opportunity for synergy here. Jira has FisyEye support built-in, so as long as every source control commit has the Jira task ID in the comment, Jira will be able to show you the code changes performed for each task.

Time to implement

The best way to implement this is to take your best developer and put her in charge of the standards. Allow her to define the coding standard, and then make her do the majority of the code reviews. The perfect person for this is one that is very opinionated on what the "right way" of developing a project is, yet will listen to other ideas and is willing to change what the "right way" means.

If you stick with this plan you will slowly find that all of the developers start coding the same way and that the general level of code quality will increase. And once everyone is working as a team and following the same rules, you then tweak the rules. Get rid of the rules that don't work, and add new rules that increase the quality even further. This is ultimately the key to the whole thing, and you should never stop changing the rules.