Software Engineering for Students A Programming Approach

348 Chapter 28 ■ Teams
The communication problem
When two or more people are working on a piece of software, they obviously have to liaise
with each other. At the very least they have to communicate component specifications –
component names, component functions, parameter types, and so on. Often such interfaces
are complex, perhaps involving detailed file layouts. Always there are queries, because
of the difficulty of specifying interfaces precisely. During the lifetime of a project someone
always leaves, is ill or goes on holiday. Someone has to sort out the work in their absence.
New people join the team and have to be helped to understand what the software is for,
what has been done and why the structure is as it is. They may need to learn about the
standards and procedures being used on the project, or even learn a new programming
language. This induction of a new person takes up the time of those who remain.
All this adds up to a great deal of time spent in communication that would not be
necessary if only a single person were developing the software. Adding two people to a
team of four does not increase the communication overhead by half – it more than
doubles it. Clearly, as more and more people are added to a team, the time taken in
liaising can completely swamp a project.
Compare the activity of picking potatoes. Imagine a large field with a relatively small
number of people. They can each get on with the job without getting in each other’s
way. If we increase the number of people, the work will get done proportionately quickly,
at least until there are so many people that they are tripping each other up. The graph
of potatoes picked against people employed looks like Figure 28.1.
If we now turn to the task of having a baby, we realize that increasing the number
of people will do nothing to the timescale – it remains nine months. The graph is shown
in Figure 28.2.
Software development comes somewhere between these two extremes. Initially, if we
increase the number of people, the job will get done faster (like the potato picking).
But, eventually, the communication overheads will become overwhelming, and the
project will actually slow down. The graph looks like Figure 28.3.
One of the gurus of computing, Frederick P. Brooks, has described this problem as
follows: if a project is late, then adding further people will only make it even later.
Potatoes picked
Figure 28.1 Picking potatoes
Number of people