Prevention

---

Prevention of this illness is particularly important because of its far-reaching consequences. Although there are steps available to cure Brittle Bones, these solutions incur substantial cost and are not to be relied upon. As a clarification, it is not suggested that no refactoring be done to the foundation. Refactoring is still an important part of the software development process, but for large projects in particular, a certain amount of upfront design is necessary to reduce the risks of everything collapsing later in development.

Design

The amount of design work that should be done on a project is a matter of great controversy these days. With Extreme Programming advocating the new approach of minimal design and the old school engineers advocating a complete design at the start, what conclusion can we come to about how to handle design? The answer is to match the level of design to the project and the team of developers. It is necessary to take into account both the project scope and the skill of each developer.

First, let us discuss how the scope of the project affects the amount of design necessary. For small projects, the number of layers that the programmers on the project are responsible for stacking is also likely to be small. This makes it easy to separate tasks and their underlying implementations such that the initial design can be minimal. As the project gets larger, the number of separate modules and layers increases. This also increases the impact of each mistake made on early code, as it is more likely to affect other code adversely and more likely to be used often. Because of this, a more solid initial design is required (Figure 9.2). This design does not necessarily have to go into details, but should provide enough information to determine what functionality should be concentrated on and what interfaces are required to communicate between modules and layers.

Figure 9.2: Effect of project scope and complexity on the amount of initial design required.

The other primary factor in deciding on the detail of the initial design is the makeup of the team. This is affected by two factors, the size of the team and the skill level of each member. As with the size of the project, the level of detail in the design is directly proportional to the size of the team. This is particularly true of large teams due to the need to break them into smaller teams for better communication. This division into smaller teams can only work if there is a design to guide the integration of code between each of the teams.

As for the importance of the skill level of each team member, the amount of design required is inversely proportional to the skill level of the team members. However, this is not nearly as linear of a function as team size. A team full of disciplined and skilled programmers needs only minimal design, but add one mediocre programmer and the team must adapt with a much clearer design to reduce the need to constantly help the less skilled programmer. Once again, this favors small projects having less design than large projects because it is much easier to create a small team of skilled developers than to find a large number without introducing some mediocre developers (Figure 9.3).

Figure 9.3: Effect of team size and skill level on the amount of initial design required.

Design content will vary by project and detail level, but the most important part of the design is always the interaction between code developed by different programmers. This generally takes the form of interface documentation, and while initially it is written as a separate document, it should subsequently be incorporated into the comment documentation as the code is developed. With the design and documentation available early, programmers can spot missing or extraneous functionality and direct their observations to the appropriate team member.

Following these guidelines should help in determining the appropriate design for your project. There are no hard-and-fast answers, but guidelines and experience will help to find the right level of design.

Balance

The art of developing a good foundation for a project is at the core a balancing act on several fronts. First, you must balance team size versus the skill level of the programmers. Next, you must balance the amount of design work versus the amount of actual code writing. Then, you must balance the amount of functionality versus the complexity of each module. Individual programmers must balance the amount of documentation versus self-documenting code.

As was mentioned in the Introduction, no silver bullet provides the perfect answer to all of these problems. However, that does not mean that there are not better approaches that reduce the risk of making a mistake. Guidelines can help to reduce risk, and that is a primary goal of software development that is too often ignored. Guidelines also give you the confidence to make decisions instead of putting them off because of fear.

Another important point to remember is that refactoring is not a bad word. In fact, few projects can escape refactoring. Therefore, do not let the fear of mistakes paralyze development. Instead, aim for reduced risk to eliminate the big problems and use refactoring to handle any smaller failures.

---