There was a time when mainframe development was the norm and teams were in close physical contact only having to walk down a few feet to interact with their colleagues. However, times have changed and access to code has to be considered in a much more serious manner. Some companies have had multiple sites participate in their development
efforts for upwards of two decades, but a majority of them have only been at this for the last 5 years or just undertaking this venture. The crux of distributed development is the ability to share code for development across sites via the network or via tape or disk.
Back in the early 1990s when I worked at Open Software Foundation (OSF), we had development occurring in our Cambridge, Massachusetts and Grenoble, France development shops as well as distributed development with HP, Dec, IBM, Bull, Siemens-Nixdorf, and others. We used a CM system called OSF Development Environment (lovingly pronounced “ODE”) which was a client/server TCP/IP SCM system based on RCS, which included a build component. ODE originated from the Carnegie Mellon University (CMU) b-tools via development by Glen Marcy, et al, and was extended by Damon Poole (later a co-founder of AccuRev, an innovative SCM tool released in 1999) making it truly client-server, adding merge tracking, increasing the performance, and making it more transactional in nature.
Even in those early days, ODE had a partner distribution tool called Software Update Protocol (lovingly pronounced “SUP”) developed by Steven Shafer from CMU. At OSF, we used SUP as a code synchronization tool that could replicate and distribute code to and from multiple sites. The SUP utility is still around today included with NetBSD distributions.
Why Distributed Development
Beginning in the mid-eighties, there have been continued actions by companies to acquire or merge with other companies. This led to companies having multiple sites with expert talent. When development projects are initiated, the talent needs to work together in a distributed yet effective manner. In the early days of code sharing, this would often be done via tapes and disk. Then FTP (file transfer protocol) or similar protocols came into existence, which allowed for sending or retrieving bundles of files via the network. With the advent of high bandwidth networks, this has allowed the possibility of real-time sharing of files without the need of transporting or sending the files. Personnel simply logged into a system from their remote site. However, while the network is broader than before, serious throughput and performance issues continue too exist.
Around year 2000, companies not only need all of their own company talent accessible to code, but there began a huge push in the industry to utilize low cost resources (e.g., developers and testers) from countries like India. This drive to lower cost has lead to a rapid increase in distributed development. Based on a 2003 survey of IT executives, the number of companies outsourcing applications to offshore service providers was expected to grow by 50% in 2004, with 35% of all users to outsource some piece of IT to offshore resources. This expectation has become a reality particularly with India.
Distributed development, as many of us know, is upon us. It is important for us to focus on how we can manage the distributed nature of projects. While there are many aspects to managing a distributed development project, this article will guide you through an approach for ensuring you have selected the appropriate distributed code access technology based on your distributed development needs.
Advice on Approaching Distributed Development
When considering your needs for code access in a distributed environment, it is important to perform an analysis of your situation. From this, then it is important to understand what distributed code access technology approaches there are and which may be best suited for you. From there, they you can identify a specific technology within a distributed code access technology approach.
The first aspect to approaching distributed development is performing a Distributed Analysis. This identifies the characteristics of each application or product that is being considered for distributed development. For each application:
- Identify the number of developers that will participate in development activities from each site.
- Identify when in the lifecycle the additional sites will begin and