What is Large in Software Development?

Examining largeness

A project can be considered large in many ways. For example, money, scope, the number of people involved, and the risks can all be large. These different “dimensions” of largeness are mostly interrelated. Some dimensions exist as a first-order consequence of the requirements and constraints. Others are derived from these first-order dimensions.

Dimensions of largeness

The individual dimensions of largeness and their interrelations are defined as follows:

• Scope: Scope is a first-order dimension of largeness created by the amount and complexity of the requirements. If a project is large in scope, we can address that issue by allowing for a large time frame, making the project large in the sense of the time required. The other possibility would be to allocate a large staff to the project. Consequently, the dimension scope influences the dimensions of time and people.

• Time: Time is rarely considered a first-order dimension in software development, and is usually considered second order. We have never encountered a company that decided to work on a project for over 20 years just to kill time. So, this is never the reason for starting a project. However, it is typically a dimension that follows another dimension. For example, if the risk of the project is high because we have several unskilled people on our staff, we will need to have them trained, which will take time. Some projects can even go on forever because nobody dares to cancel them.

• Money: Money is also typically a second-order dimension. It means high costs are always a consequence of the growth of other dimensions. At least, we’ve never seen a project start just because there was a lot of spare cash lying around. On the other hand, a lot of projects waste enormous amounts of money without anyone batting an eye. But this is always a consequence of one of the other dimensions. For example, a large team might cost a lot of money, but the question of whether it is necessary to have such a large team is rarely raised.

• People: This is a different matter. The number of project members is usually a first-order dimension. It is possible for the size of a project’s staff to be a side effect of the project’s scope. However, sometimes projects are staffed with a lot of people—in the worst case, right from the beginning— mainly to show the importance of the project or of the project management. The number of project members is not related to the amount of developers only but also, for example, to the number of customers. The more customers are involved in the project, the higher the risk of contradictory requirements.

• Risk: Risk is a more complicated dimension because it can refer to almost anything. For example, team size can be a risk, but focusing on a hot technology also carries a big risk and is often followed by having to spend money to train the staff, among other things. However, risk is typically a second-order dimension.

Therefore, the two initial reasons for scaling a project are scope and people. We can run a large-scope project with a small team. But large-scope projects are almost always developed by a large team—especially in large companies.

Typically, if a project is large in terms of people, all of its other dimensions are likely just as large. For example, we will hardly ever find a large team working on a project with a narrow scope, a schedule of only three months, or a budget of only a few hundred thousand dollars. The project itself might not carry any extraordinary risk, but scaling all the project’s dimensions implies a risk of its own. For instance, if a lot of money is involved, there is a high risk that a lot of money will be lost. Or, if the time frame is extremely large, the risk that the project will never be finished increases. In this course, we focus on projects with large teams. However, because large teams usually scale the dimensions of scope, time, money, and risk, all these other dimensions will not be ignored.

Raising large issues

Of course, large is no well-defined magnitude, which is also true for the largeness of a team. Will a team considered to be large if it contains 2, 10, 100, 1000, or even more people? And what impact does every additional order of magnitude to the staff number have on the process?
For example, let’s look at its influence on communication:

• Two or more people: If only one person develops a project, that person has (hopefully) the big picture of the project in mind. They know the whole system in terms of code and design. As soon as another person is added to the project, these two people will have to communicate with each other. Communication is the only thing that will enable both developers to understand what is going on and to further coordinate their efforts. For example, it would be annoying if they were to both work on the same programming task unknowingly, only to find out once they began to integrate the code.
• 10 people or more: With teams of this size, we have to start coordinating members’ efforts and their communication. We have to explicitly establish communication channels in order to discuss topics with the whole group.
• 100 people or more: Even if an open-plan office is available, teams of this size will not fit in a single room. Therefore, we have to ensure the “natural” communication, which normally takes place inside a single room by explicit strategies.
• 1000 people or more: Chances are high that this team will not only be distributed over several rooms, but also over several buildings, perhaps over several different locations. Consequently, the people on the team are unlikely to know all their teammates.

This example shows not only that large is relative, but also that scaling can lead to different consequences.

Communication is the only thing that will enable both developers to understand what is going on and to further coordinate their efforts. For example, it would be annoying if they were to both work on the same programming task unknowingly, only to find out once they began to integrate the code.