Code Decay Triangulation using Metrics, Experts ’ Opinion and Defect Counts

In contrast to physically engineered artefacts, software does not deteriorate through use. Code quality, however, may decay (i.e. deteriorate) through the process of software evolution (a.k.a. maintenance). Such decay may have negative human, technical and economic consequences. For example, software maintainers may find that the code is becoming excessively complex. Evolution may become more time consuming and difficult than it should. Other stakeholders may not receive the functional improvements they are waiting for in time. Unexpected side-effects may emerge when new changes are implemented. Defect fixing may get harder. And so on... The problem of code decay (a.k.a. code aging, excessive complexity, ‘spaghetti ’ code) has been identified and discussed a long time ago [e.g., Lehman 1974, Parnas 1994]. There are many code decay empirical studies in the literature [e.g. Eick et al 2001]. There are, at least, three different ways of trying to assess the level of code decay in a particular system: direct measuring of the code through software metrics, surveying experts ’ opinion about code quality and using indirect measures (e.g. process related measures such as defect counts). It isn’t known whether these three different ways will converge to the same insights when applied to a particular system. In this extended abstract, we briefly report the findings of a case study in which software metrics