Think of the problems you encountered during your last project, then imagine the team spread across different floors or buildings, or even continents! The problems and pitfalls are greatly magnified to a point where development is severely hindered.

This is a typical distributed development team. The personnel involved in the project are unable to have direct face-toface communication. I will discuss common problems that can be encountered when working in this environment and talk about solutions that will greatly improve project development.

First, let's start by defining an example team. A global project has been proposed and the only problem is that some members of the team are based in the UK, and some in the U.S. This is not only multi-site it is also intercontinental, where time of day becomes a big issue. Figure 1 shows the organizational structure of our development team.

 
Figure 1: The organizational structure of the development team

The distribution of the staff means it is both difficult and expensive to all meet face-to-face, so solutions need to be found to facilitate a good working environment.

Definition and Design
The key to any project is good communication. It is absolutely vital that everybody knows what's going on, and that people can find out what they need to know. There are two key areas where communication is vital - within the company and between development teams.

Business is the driving force behind any project. A project is not even started unless there is benefit to the company, so it is up to the business to define what it actually wants and expects. Documentation is the core of a successful project. Without clearly defined goals and expectations, a project can begin to shift scope and flounder very early on in the development cycle.

For development to begin, a functional specification must be written. This defines the scope of a project - its goals and expectations. By writing this document in a nontechnical language, everybody involved in the project knows what is required. A poorly written specification means that there is a chance that somebody will misinterpret the requirements and unexpected results are assured. This not only causes friction between the business and development teams, but it can also jeopardize the project time line, as changes will inevitably need to be made.

The next document is the technical specification. This takes the functional specification and builds upon it, defining how the goals and expectations will be met. This is written in a language that clearly defines how the application will work, and is in enough detail for the development team to understand its implementation. By sitting down and thinking the requirements through, the development cycle can be defined and documented.

An important step to take after the creation of these two documents is sign off. The appropriate staff from key parties involved will review these documents and agree if they are a solid definition of the project. Without this sign-off step, when the project is further down the line and people's expectations have changed, chaos can ensue.

Let's take our global development team we talked about. Without solid documentation there is no standard, and each team will take a slightly different course. This can mean that the final outcome will be vastly different than what was initially envisaged. With good documentation, the two teams can work in unison and meet the project's requirements.

Communication
Communication becomes even more important when different facets of the project are being worked on independently. We have already discussed specifications and documentation, and these go a long way to facilitating communication. But there should always be an open forum for the exchange of ideas.

One of the most common things that has to be communicated is change. During the life cycle of the project, technical issues and changes in expectations arise that need to be accurately documented and communicated to everyone. There are many tools available that facilitate this. Personally, I use a very simple application that was developed in-house to track changes and issues. These applications can track the life cycle of all issues and distribute details to the appropriate people. This provides full auditing of the documentation and a history of changes.

I feel it's important to mention that no matter how helpful these tools are, without good data, they can become a hindrance. For the most part, changes should be written in a highlevel language so that everyone can easily understand what has changed. With technical reasons it is not always possible to break this down to easily understandable terms. Even so, I find it is good practice to always try to make it easy to read, as change affects everyone, including nontechnical staff.

The second line of communication is interdeveloper. In the case of our example team, the developers are split over two continents, in two different time zones. This means that the two teams may not be working at the same time, so good written communication is paramount. Not all projects are spread so far apart, but the principles apply equally to both.

A development plan is a definition of each part of an application, and a breakdown of how it is achieved. For instance, in the case of a FuseBox project, the application is broken down into a series of files containing displays, queries, and actions. A development plan for these types of projects will consist of a list of the application sections and their component files. Another benefit of producing a well-defined project plan is that it also gives a very good indication of the size of a project, and hence the development time.

From a clear development plan it is easy to define tasks and set priorities. With two or more separate teams, it is important that everyone knows what they need to do and when they need to have it done by. Collectively deciding task workloads and completion dates help plan out the whole application ahead of time. It is quite common for one team's work to depend on the other's. I find that leaving some less critical tasks unassigned allows developers to continue working in the event of any unexpected deviations from the plan. A complete plan allows the project to continue moving forward in the event of deviations or technical issues. I will discuss the former in the next section.

Time to Start
When the development process begins, there are many things developers can do to help the project along, other than writing code. One of the most important is code commenting. By accurately commenting the code, any other developer currently working on the project (or in the future) can work out what different parts of the code do. A useful standard to use is FuseDocs. Although designed specifically to work with FuseBox applications, the principles can be used in others.

A FuseDoc is basically structured text, based on XML, that fully describes the file. The packet used in FuseDocs starts by defining the name of the file and what version of FuseDocs is being used (see Listing 1). Full details of XML are beyond the scope of this article, but there is a wealth of information available in books and on the Internet (for example, www.fusedoc.org). The next few lines in the packet describe the purpose of the file. It is written as though you are the page and you are describing your function. It has been designed this way so that everyone easily understands even though they are not the original developer.

The final section describes the inputs and outputs of the file. These are what are required to make that file function correctly within the application. By defining these, anyone can find out what is going into the file, and what is expected to be left out. A typical FuseBox application development cycle usually includes a cycle of just writing the FuseDocs for the application so that all the developers know how the application will flow. This is only a brief overview of FuseDocs, but there are many articles available about this and FuseBox.

Version Control
Version control is a system whereby all changes to files are tracked and stored as different versions. These may be as unsophisticated as making several copies of the file, or automatically tracked by a dedicated application. I prefer the latter as it saves disk space and keeps an audit trail of what was changed and by whom. There are many different packages that perform this function, and these are available as either open source or commercial.

For the open source route, a popular version control system is CVS. This can be downloaded freely (www.cvshome.org), and is a very comprehensive system. It's flexible and has more features than most people will need. The only real downside is that it is driven by a command line. This makes it quite cumbersome to use and unfamiliar to people used to graphical interfaces. There are other open source projects that provide graphical interfaces, and these can be quite varied in their operation. If you have the time, download a copy and try it out.

Commercial packages tend to have richer graphical interfaces, and can be much easier to use. PCVS is one such package that is commonly used. This provides client and Web interfaces, and has the added benefit of support. It is similar in functionality to CVS, and as such is quite comprehensive. Another package is SourceSafe. This is produced by Microsoft and is usually included in all of its development environment distributions.

All these packages have several things in common. They all support multiple users, archive changes to each version, and have the ability to mark a file "is locked". This means someone is working with the file and the software will not allow you to enter changes unless you are the person who locked it. This is particularly important when several people are working on a project. Once the correct changes have been made, the file is checked back and unlocked. Another major benefit of these systems is that they allow you to roll back to previous versions. This means if a mistake is made, the previous version from the archive can be retrieved. These benefits alone mean that version control should be a key part of any project.

Working Practices
At the end of the day, all the technology in the world is not going to help if it's never used. That's why establishing good working practices is important. Just as I have explained earlier, communication is the basis of good practice. Imagine our example team again - on two sides of the planet, meaning as one team is almost finishing for the day, the other is beginning. What if one team didn't report their progress or problems they'd found? The team relying on that report to continue work is left not knowing where to start, and cannot continue with their own work. It's not a showstopper; they could probably work out where the other team got to, but it would cost valuable time.

There are several methods of communication available that enhance these best practices and allow a feeling of solidarity. E-mail is probably the most important, as it's available to almost everyone these days. Instant messaging can be extremely beneficial, especially if the teams are working at almost the same time. When used for business purposes it can save considerable amounts of time, as most people will answer an instant message more quickly than an email. Conferencing is another key practice that should be established, and is easily done through a variety of systems. The ability to talk to many people remotely is invaluable, allowing a "virtual" meeting. These systems can also come with whiteboard facilities, as well as application sharing. The latter allows you to demonstrate applications collectively, whereby everyone sees what you are doing with an application.

Whatever the structure of your team, these concepts apply to all. The key to success is communication. Without it, these projects are going to be severely hindered, or even doomed to failure.