Integrated Tools Enhance Distributed Development

and forth a few times, should be resolved through a meeting or tele-conference.

Tools and Data Repository

Tools interact with the data repository (or repositories). Looking at the previous three areas, it is clear that tools play a critical role in distributed development. The key, from my perspective, is ensuring that all sites, and the tools at each site, have access to all of the data, not just a portion. Data, along with good tools, is the key to making good decisions. (OK, good judgement and experience may play a part as well.)

There are three basic models for distributed development when it comes to data.

1. central repository with distributed access, through the web or otherwise
2. distributed repository with appropriate pieces at appropriate sites
3. replicated repository with local access to the local site.

I strongly recommend the third model. But if your tool sets require a number of different repositories, the recommendation is less strong - it's not easy to build distributed solutions on tools that don't share a common repository. And it's risky.

A central repository has its place, for example, if there are only a few users outside the main site. Solutions involving a thin client (e.g. remote desktop), with workspaces hosted at the main site can work reasonably well. But move the workspace (or the tools), out to the remote site and some delay problems appear. Try doing a workspace differences operation against your repository over a 100 Kbps link as opposed to a 100 Mbps LAN. Not a big problem if your workspace only has a few megabytes in it.

A distributed repository has applications where it is necessary to keep data away from some of the sites. This is the case often in a contractor/sub-contractor model, where the sub-contractor is only supposed to see a specific piece of the puzzle. And it's difficult to decide how to partition the data. What data goes where? How often is it synchronized back to the main site? How do I capture a backup which is consistent?

More often though, we're dealing with organizations which want to share information across sites. Each site needs to make timely decisions, even when the other sites have gone to sleep for the night. In some organizations, the user's workspace is on his/her laptop and the user is moving from site to site.

A replicated repository strategy meets these needs. The repository looks the same from any site. The tools work the same at every site. At a minimum, a master site (or a quorum of sites) is required to sequence transactions so that all sites can ensure that they are processed in a consistent order, with the same results.

A replicated repository has other benefits as well. Each site acts as a backup of all of the other sites. This also forms an important part of any disaster recovery planning. And in the case of a disk crash, or any other interruption of service to the local repository, it's easy enough for a user to connect to a remote repository, even if at a slower speed.

Choice of Tools

When it comes to talking distributed development, there's too much focus on the version control repository. That's important, sure. But it doesn't contain the key information. It's the management information, not the code base, that's going to make distributed development work. It's the process and the communication channels. A version control repository does little to help here.

Management data spans from requirements through test data, from documents through customer tracking data. It's not easy to do this if you're planning