Good configuration management (CM) is seldom easy. It can become even more difficult when software-development teams are distributed across the globe. As the outsourcing trend in U.S. wired and wireless companies continues to grow, so too will the headaches associated with distributed development. But as experience has taught me, most of these headaches come from unexpected sources.

Several years ago, I was the manager of a small software team in Portland, Ore. In addition to developing product code, we had to coordinate source control and daily builds with two other teams. One of those teams was the parent company, which was located elsewhere in the U.S. The second team, which was outsourced, was based in India.

Surprisingly, our team encountered fewer configuration-management difficulties with the team in India than we did with the corporate team. The geographic factor didn't pose a major problem for us. Rather, the difficulties stemmed from a difference in the degree of CM process maturity and discipline.

The team in India did present the greatest challenge in terms of software-code transfers and daily product builds. The problem was that we didn't have a secure VPN connection. By using PGP encryption with public keys, however, we successfully transferred all source code, header files, libraries, documentation, and the like between our team in Portland and the outsourced group in India.

The careful planning and distribution of the various application modules also contributed to the success of our joint code-development work with the Indian team. For the most part—aside from a few shared libraries—the group in India worked independently from the Portland team. Synchronization of the daily builds was not generally required. Compared to the corporate team, however, the team in India demonstrated a greater appreciation for the benefits of configuration management.

The time difference between our Portland and India teams was rarely a problem either. E-mail messages, which contained both progress reports and software-related issues, were sent at the end of each day. They arrived just in time for the next team to start work. It was almost like running two shifts of development.

Unfortunately, the corporate team was not as conscientious in its adherence to basic CM procedures. Its members often forgot to check in their source-code files for weeks at a time. Version control was used sporadically. Although changes to shared libraries (DLLs) were common, they were rarely documented or communicated to the other teams. To find a critical part of code or shared library, it was not uncommon for Portland team members to spend hours tracking down the responsible programmer in the corporate office. Often, this was done by phone because timely e-mail responses were yet another problem.

In the end, we were able to meet our product release dates—but not without considerable pain. We came to realize that most of our problems with distributed development were the result of poor configuration-management practices. We also suffered from a lack of management enforcement of the existing CM procedures.

I'll save the details of our homegrown CM system for another time. It's sufficient to say that we had a documented and repeatable process for storing our source code, versioning the libraries and executables, and performing builds on the trunk and branches.

In a distributed development environment, good configuration management is not so much an issue of technology. Rather, it's one of communication, discipline, and practice. Our team in Portland used a homegrown, non-enterprise CM system to develop high-grade software applications with teams in India and the corporate office. We found that the following factors contribute to a successful development environment:

• Ensure that an adequate CM system is in place. At the very least, it should provide an automated build engine; easy source-code control; a method for versioning all code and related files; and a way to reliably provide for both trunk and branch builds.
• Make sure that good CM practices are followed first by your own team.
• Clearly communicate your CM requirements with the other teams. Listen to their concerns.

I'm not saying that the commercially available, enterprise-grade CM tool suites wouldn't have made our job easier. But tools and technology must always be complemented with good communication skills and basic engineering discipline. Please share your thoughts or experiences with me at jblyler@penton.com.