Does code decay? Assessing the evidence from change management data

TLDR

Large software systems increasingly find change—needed for new features, hardware updates, and bug fixes—more difficult over time. The authors aim to study code decay by defining it and proposing quantitative indices that act as symptoms, risk factors, and predictors. They analyze fifteen-plus years of change history from a telephone switching system, applying the proposed indices to assess statistical evidence of decay, with developer corroboration. The study finds mixed but largely persuasive statistical evidence of code decay, corroborated by developers, and indicates that perfective maintenance may help retard it.

Abstract

A central feature of the evolution of large software systems is that change-which is necessary to add new functionality, accommodate new hardware, and repair faults-becomes increasingly difficult over time. We approach this phenomenon, which we term code decay, scientifically and statistically. We define code decay and propose a number of measurements (code decay indices) on software and on the organizations that produce it, that serve as symptoms, risk factors, and predictors of decay. Using an unusually rich data set (the fifteen-plus year change history of the millions of lines of software for a telephone switching system), we find mixed, but on the whole persuasive, statistical evidence of code decay, which is corroborated by developers of the code. Suggestive indications that perfective maintenance can retard code decay are also discussed.