Structural Epochs in the Complexity of Software over Time

A case study using a new complexity measurement framework called Structure 101 tracked the structural complexity of three open source software products through their different releases. The analysis found that, as these software products evolved, a large proportion of structural complexity in early releases at the application-code level progressively migrated to higher-level design and architectural elements in subsequent releases, or vice-versa. This pattern repeated itself throughout the evolution of the software product. Refactoring efforts successfully reduced complexity at lower levels, but shifted the complexity to higher levels in the design hierarchy. Conversely, design restructuring at higher levels shifted complexity to lower levels. If this trend holds true for other software products, then mere code refactoring might not be enough to effectively managing structural complexity. Periodic major restructuring of software applications at the design or architectural level could be necessary.

Traditional Complexity Metrics

Complexity's relative impact varies depending on the abstraction level in the design hierarchy. For example, cyclic dependencies between software packages and components have a greater impact than excessively complex code at the method level, because a change in one package or component can adversely affect all dependent packages or components.