Conventions that can be used for distance work in a team project

Question

What sort of conventions would you advise when doing some distance work (say through CVS or SVN) on a team project? More specifically, what can be done to avoid someone doing widescale changes, which might be necessary, and running the risk of confusing/delaying other team members? If testing is necessary, how should it be carried out so code isn't polluted with instructions that will need to be cleared out before the application is to go into production? I'm interested in anything that has to do with methodology but also any small tips that could enhance communication such as leaving TODO comments in the source code.

Answer 1

Communication is more key than convention. My team is split, half in Europe and half in the US, and our success comes from clear, regular communication:

• Daily 15-minute conference call where everyone says the area they are working on. Followed up by an email summary.
• Weekly 2-hour video conference where someone presents a complex piece of work.
• As lead, I talk through each task with a developer for at least a few minutes before they start, check in with them at least once a day by phone, IM or in person; and expect a brief review when the task is complete. The point is not to check up on them to make sure they did it right* - they wouldn't have been hired if we weren't 100% sure they could.

The point is that ritual communication establishes a baseline habit of regular communication and that keeps everyone in sync. The mandatory bits make everyone comfortable enough to pick up the phone or approach a colleague every time they work on something the other might need to know.

Also, please don't leave TODO comments in source code. Throw a UnsupportedOperationException/NotImplementedException until you're ready to implement, and then implement it fully.

*Right doesn't mean perfect. There's always a better design, better way to code something, and continuous communication facilitates continuous feedback.