Multi-Country Software Coding

By Jacob Palme, e-mail jpalme@dsv.su.se.
First version: 17 September 1997, last revision: 6 February 1999.


Contents

Scope of research
Research topics

   

Links

Computer Mediated Communication
Master's thesis ideas (in Swedish

 


Abstract

Why Multi-Country Software Coding

International cooperation can certainly be valuable in many stages of software development. It can, however, also cause many difficulties. Especially in the stages of actually producing well-working and running code, the ideal environment is a group of dedicated developers, sitting close together in a protected area, which encourages cooperation and discourages external disruptions and influences. The ideal size of such a development group is about five persons. With more participants, internal communication becomes so much more cumbersome that productivity may not increase with the added personnel. International cooperation can be valuable before and after this central stage of the actual coding. Before the coding stage, international cooperation can be useful in user studies and user specifications, and after the coding stage in testing. But the actual technical specification and software coding is best done by one group at one place.

Sometimes, however, software development is part of an international cooperation effort, in which development has to be done by people in many countries. One example of this is development done within the research projects funded by the European Union. This paper is written to collect experience from one such project, the Web4Groups project, in which development was split in five countries. The conclusions in this paper consists both of recommendations of positive experience and recommendations for avoiding problems which we encountered in the Web4Groups project.

This paper is primarily written as an aid to future EU-funded research projects, to learn from our experience.

A note: Very little is written in this paper about collection of, and specifying, user requirements. This is not because this is not important, but because this paper is intended to cover the technical stage of development. Of course users should be involved in several stages of the development, as shown in the figure below:

Why is Multi-Country Software Development Problematic

When more than one person is working on developing the same software, close cooperation is necessary. Portions of the code written by one person will influence portions of the code written by another person, and one person may get stuck with a design problem which can only be resoved by change in the code for which another person in the group is responsible. This is true even if the software is carefully designed to minimize the need for such dependence. Even worse is if different people in the development group have different ideas of how the software is intended to work.

When software is designed by a small team of people sitting together, these can easily overcome such problems by immediate face-to-face communication. This is not possible in international cooperation, with developers sitting in offices at large geographical distances. Communication will primarily be through e-mail and telephone, combined with audio and video meetings and/or face-to-face meetings. The travel cost for face-to-face meetings and the disruption they cause to normal work means that they cannot be held frequently enough. And problems encountered often need immediate solution, cannot wait for the next scheduled face-to-face meeting.

It is a well-known fact, documented by much research in the area of CMC (Computer Mediated Communication), that while e-mail and similar communication tools are very useful, they also have known problems. People discussing issues by e-mail easily get stuck in contrary positions and discussion continues endlessly on issues which would best have been solved by immediate solutions. It is much easier to fully grasp complex issues, understand each others position, and find mutually good solutions, in small face-to-face meetings in which only the directly involved people participate. Formally scheduled face-to-face meetings to which people travel paradoxically often become too large for effective problem solution.

How can these problems be overcome?

Below is suggested a number of ways to reduce these problems and to carry multi-country development work to a successful completion.

Understand each other's models

Even when people use the same words, they may mean different things with what they say. Even people who are highly skilled and very competent experts may have very different models of the world and of their tasks. Such differences are easily overlooked at the start of a project, but will then crop up later on. To avoid this problem, it is very important that the primary developers in a project spend enough time at the start of the project to learn each other's models. Ideally, a new project should start with a series of tutorials, where each major developer can explain in depth his/her model of the area and the development task.

A well-known psychological method to increase people's understanding is to ask participants to state, in their own words, the view of other participants, and then for the other participants to listen and check if they have been understood correctly. This method is known to be very useful in negotiation and resoultion of differences in face-to-face situations, and should be used also when people are at difference locations.

In our project, Web4Groups, the goal was to develop an advanced messaging system. There was, in our project, a conflict between two different models of our task. One project partner had long experience with developing similar software, and had developed an advanced view of the data base structure, based on a structure of objects and links. Other partners had less experience, and had a more down-to-earth model close to the actual user interface of existing software like e-mail. I am not claiming that one of these models is better than the other. They both have their advantages and disadvantages. However, we should have spent much more time in the beginning of our project understanding each others' models.

Specify Interfaces between Modules

International cooperation in software development requires that the task to be done is split into separate modules, with well-defined interfaces between the modules. Especially when development groups in different countries are responsible for different modules, this is very important. The interface between the modules should ideally be designed early in the project and not need too much later changes. We believed we did this in the Web4Groups project, where we defined a detailed Applications Program Interface (API) between the tasks of the different partners. However, we found that we had to extend and modify the API many times during the project. This is perhaps unavoidable, but more initial work on developing a more complete API might have saved problems in later stages of the project.

Written versus Spoken Information Exchange

Our experience is that one should not rely too much on written technical documentation for exchange of information between geographically dispersed development group. Detailed written technical documentation is too difficult to read and grasp for developers in other places. Tutorials, where one or more developers explains how the software is designed, are more important than technical documentation. Technical documentation is of course needed to make it possible to go back and change software at later times, and the interfaces between the modules must of course be documentet in written format, but technical documentation is not the best medium for information exchange between dispersed user groups. Some of the effort, which we spent on developing documentation, would have been better spent in developing and presenting tutorials.

Use Explicit and Precise Language

It is very important that people communicating internationally are very precise and explicit in their language. Irony and sarcasm should be avoided or clearly marked with the traditional ":-)" sign. It is very important to clearly specify what is an urgent and important requirement, and what is just a discussion idea which does not need immediate resolution. Agreement on additional notation to clarify this may be useful. (In face-to-face meetings, body language and inflections of speech are used to convey this very important information.)

Central Project Management

Even if development is split between developers at many places, there should be one single central technical manager. Local technical manager at each site is of course also necessary, but a central technical manager is even more important. The task of this manager is:

  1. To have a full technical knowledge of the tasks done by all the developers at all geographical sites.
  2. To be impartial in disagreements, to try to solve problems by understanding each person's views and problems, and trying to find solutions which all can accept. Critical in this task is understanding.
  3. To actively follow what happens at all developing sites.
  4. To keep the task list, see separate segment below.
  5. To use e-mail, telephone, and, when needed, travel to the different groups to talk to people and understand their problems.
  6. To summarize discussions and issues and propose solutions.
  7. To stop discussions on issues which are fully clarified and where solutions, not more discussion is needed.
  8. To ensure that all developers are all the time aware of which are the most urgent tasks for them. This can be done, for example, by making a list of the most important tasks to be done by each developer and sending this list once a week (but covering several weeks of work) since changes will often occur in the priorities on the list.

Fire Alarm cases versus Progressive Work

During development, sometimes cases occur which could be called "Fire Alarm" cases. These are cases where one developer cannot continue unless another developer makes some change in his software modules. Real fire alarm cases need changes in priorities. However, it is important to recognize what really is a fire alarm case. Every time a developer wants some design change, this need not be a fire alarm case. Since fire alarm cases are given high priority, there is a risk that developers designates their needs as fire alarm cases just to get high priority. The central technical manager should investigate each fire alarm case and assign the necessary high priority to the case when this is really motivated.

Task list

Every large software development project has one or more task lists with things which has to be done and priorities on the tasks. Even if local groups have their own local task lists, an international project needs a joint task list for all the development. This task list should contain priorities of what is more important and should be done first. However, developers sometimes need to combine tasks with higher and lower priorities because they affect the same code and are easiest done at the same time.

During a project, the task list tends to grow in size and can easily be disorganised. For example, the same task may appear several times with different wordings. To get a well-organised list it is important that one person has primary responsibility for the task list, with someone else as backup only if the person mainly resposible needs help or is unavailable. Preferably, this should be the same person as the central technical manager.

All developers, as well as user representatives, can contribute to this task list, but the actual addition of new items to the list should only be done through the person who is responsible for running the task list. Important is that the contents of the task lists is regularly communicated to each team member, for example by an e-mail containing the tasks with highest priorities for this particular team member.

Setting priorities

The task list will soon contain much more than the group has resources to realize. This means that setting priorities in this list is important. However, such setting of priorities is difficult. The main problem is that too many tasks get too high priorities on the list, so that the list does not work well as a means of distinguishing priorities. In discussions of priorities, it is easy for a group participant to argue strongly for the highest priority of his current idea. The technical manager must be able to distinguish between real strong needs for one participant (fire alarm cases, see above) and cases where a participant proposes high priority just to get his pet idea implemented. If agreement cannot be reached, voting or asking user groups can sometimes be methods on setting priorities on controversial task items. Asking user groups is of course only meaningful if it is possible to specify how the alternative choices will influence the way the software will work as seen from the users.

If a task list starts with giving priorities 1, 2, 3, 4 and 5 with 1 for the most important and 5 for the least important item, there will soon be a problem that much too many tasks have priority 1. Rather than changing all the priorities of all the items on the list, a simpler way is to use decimal numbers, and split 1 into levels from 0.5 to 1.0. If, at a later time, there is still too much accumulation of items at the same level, two decimals can be used, for example splitting 0.5 into 0.50, 0.51, etc.

Face-to-face meetings

Face-to-face meetings to solve difficult technical design problems are often more effective if they involve only the people actually involved. If a face-to-face meetings grows large, they will sometimes be less effective. There is a human tendency in all face-to-face meetings to adjust the level of discussion to the least competent participant. (By competent is meant compent on the particular issue discussed. One person who is generally very competent may have very low competence on a special technical issue which is only understood by those developers which encounter this problem.) This means that additional people with bright ideas but not really involved in the problem can disrupt a face-to-face meeting. This is usually no problem if all the developers sit close to each other. If one of them has a problem, he/she goes to the other person involved and discuss the issue, involving the manager if needed and let other people get involved only as needed. In international cooperation projects, however, face-to-face meetings are usually 2-3 day gatherings of all developers, and sometimes also other project participants, at one place. Such meetings would probably work better if they are organised into several get-togethers of smaller groups which can work more efficiently. The problem is, that if for example ten developers meet at one place at one time, and say three of them need a closed meeting to resolve their problems, what should the other seven people do during this time.

It is not so easy as to say that the other seven people should form other groups, because reality is not so simple. Very important is that the other seven people, because of lack of things to do, go to the meeting of the three really involved people. The addition of these seven other people can disrupt problem solution in the small group.

Agenda setting

Because it is so important to keep the group sizes down, agenda for face-to-face technical meetings with more than 3-4 participants have to be developed in a special way: Ask each developer which items s/he wants to discuss, and with whom, and then split the meeting into a series of small scheduled sub-meetings (if possible in parallel) with the people needed for discussing this particular item. Important and highly controversial issues should of course be discussed in plenary.

IETF has a rule that decisions in face-to-face meetings are always temporary only, and that real decisions are made through e-mail. The reason for this is that new facts and ideas often crop up after the face-to-face meeting, which may cause a need to change the decision taken. In multi-country development more decisions can probably be taken at face-to-face meetings, but one should always be willing to change such decisions, and there should not be a rule that a decision at a face-to-face meetings must be adhered to until the next face-to-face meeting takes place.

References

The Genesis of Web4Groups by Gernot Tscherteu at URL: http://www.Web4Groups.at/w4g/project/genesis.html.