How frequently have you merged your code with changes from the mainline, only to find that the result doesn't build, or it builds but it doesn't work? Monthly? Weekly? Daily? Hourly? Or worse, how often have you made changes that broke the build, requiring you to quickly correct the problem while getting flames from your team members?
Perhaps your team has recently expanded, added distributed team members, or started doing outsourcing with a team half way around the world only to find that code churn has not only gotten worse but now it is also harder to coordinate with others to track down and correct the problem. Don't despair. You are not alone, and this problem has straightforward solutions using extensions of practices you are probably already familiar with.
I've looked at the development process at hundreds of shops, from small collocated shops all the way up to 10,000-user shops doing global development, including ISVs, financial institutions, networking vendors, and government organizations. There are fewer differences between the development processes employed at different shops than you might imagine. The bottom line is that source code moves from a state of immaturity to a state of maturity through a set of stages and integration points that is similar to an organization chart.
In my travels I have found that many tried-and-true best practices originally developed for collocated teams can be applied as-is or extended to global teams. Usually, global teams have the exact same trouble spots as collocated teams, they are just amplified in proportion to the amount of physical separation. In other words, improving your process is a good thing in general and even more so when every weak area is amplified by distance.
