There are many reasons that organizations or government agencies use distributed development. Whatever the reason, a software development team, and indeed the entire product team, needs to do all it can to ensure that development proceeds smoothly.
Put a bunch of developers in an office with a mission to produce a specific software product and it’s only a matter of time before the product starts appearing. Now throw in a new requirement that dictates that development will be done by three or four teams distributed across different cities, countries, or time zones, and the results are no longer so predictable. How are the different teams going to work together to get the job done? Isn’t it better just to put everyone together in the same office?
There are many reasons that organizations or government agencies use distributed development. Maybe it’s a NATO project where multiple countries have been politically mandated to develop the software. Perhaps different subcontractors have different areas of expertise that need to come together. Maybe a series of mergers has left a particular software team spread out over several locations.
Whatever the reason, a software development team, and indeed the entire product team, needs to do all it can to ensure that development proceeds smoothly.
In any event, distributed development will require more effort on your part to encourage team members to communicate. Because the nature of distributed development is that teams are spread out, it’s likely that less communication will take place. To handle this problem you need to remove the barriers to communication. This can be done, for example, by supporting on-line code reviews—stored in the CM repository—or through on-line meetings for design reviews, change control boards, problem review boards, etc.
As your team members can no longer walk down the corridor to chat with peers and find out who is doing what, it’s critical that your CM repository and tools provide a clear communication of the project picture – priorities, assignments and status. The repository or tool that you use must collect data better (automatically when possible) and it must present the information more readily and in a pro-active way. This is to ensure that team members, otherwise unwilling to take the effort to get information, don’t proceed with their job with less information than they might use in a non-distributed environment.
For proper global development, there are three CM repository scenarios I'd like to discuss: distributed data, centralized sites, and synchronized multiple sites.
Divide and Conquer – Distributed Data
The general approach to using distributed development is to divide and conquer. In this approach you spread the functionality along logical boundaries, such as are naturally defined by devices, system layers or subsystems. This reduces inter-site development conflicts.
Every so often you bring the teams together with all of the software from each of the sites, so that an effort can be made to integrate them together. This has some merit, but also a few drawbacks.
For one thing, you must ensure that infrequent integration does not cause long delays while you work out the integration issues. This strategy flies in the face of continuous integration practices.
The integration will take some time, since it is done infrequently – so there will be more problems to diagnose and solve. By the time a successful, consistent integration is attained, development will have moved on and integration work will have to be merged back into each site.
Another issue with this approach is that it takes a considerable effort to partition the software among the various sites. This is not just an initial partitioning problem, but an ongoing problem as the need for new software components arises, and as the teams and expertise bases shift over time. The strategy of “divide and conquer” works best when it’s only the deliverables (i.e. not the