For more than 30 years, the concept of modularity has been seen as a key enabler for the development of large software systems. Modules help manage the complexity of development by breaking a system into units of software that individuals or teams can build [Dijkstra 1968], [Parnas 1972]. Modules enable the hiding of decisions behind an interface, allowing the individual or team responsible for a module to make progress independent of the decisions made by individuals and teams responsible for other modules [Parnas 1972]. Modules enable the enforcement of boundaries between parts of the software system, enabling the interchange of one part for another [Dijkstra 1968], minimizing the impact of changes made to a specific part of the system [Parnas 1972] and reducing the time to build the system when changes are made (separate compilation) [Liskov et al. 1977].

To help programmers maximize these benefits and more, most programming languages provide explicit support for expressing modules. For instance, many object-oriented programming languages, such as Java [Gosling et al. 1996], support a fine-grained notion of modularity through the definition and implementation of abstract data types. Support for coarser-grained modularity can sometimes be found in companion technologies. For instance, OSGi, a companion technology to Java, enables classes to be divided into bundles that are then restricted to communicating through well-defined interfaces [OSGi 2007]. Developers also often use informal means to express modularity, such as using a hierarchical file structure to distinguish modules.

Ideally, each module a developer expresses would capture one coherent concern. For example, in a software system that controls a train, a developer may define a module that interacts with the train’s brake so as to ensure coherent reasoning about the operations of the brake. In reality, concerns cannot always be separated so cleanly. Returning to the train example, a developer might define a different module to interact with the signalling system of the track on which the train runs. In some cases, the brake and the signalling system functionality may have to interact so closely that there is a need to implement signalling system functionality in the brake module; for instance, emergency signals may require immediate application of the brake. These tight interactions can lead to the need for multiple modularizations of a system. This need has been well-articulated as the motivation for aspect-oriented software development [Kiczales et al. 1997], [Tarr et al. 1999] and emerging aspect-oriented programming languages, such as AspectJ [Kiczales et al. 2001], improve a developer’s ability to modularize the system by enabling the modular expression of crosscutting concerns.

Modules are thus an entrenched organizational approach to constructing software. But is modularization providing the promised benefits? In this chapter, we investigate whether the promised benefits are being seen by analyzing the archives of three open source software systems to determine answers to the following questions:

We begin our account of this investigation by describing the systems we chose to include in our analyses. Because answering these questions across different software developments requires a definition for what constitutes a comparable change to these systems and a definition for what constitutes a module across the systems, we then describe how we defined a “change” and a “module.” These definitions provide a basis for our analyses, which we then describe in detail before summarizing our results.