|
Subtitled "Assessing the Evidence from Change Management data."
The software system studied is a 15 year old telephone
switching system to which new features are continually being added.
Statistical methods are applied to data from the version management system.
An economic model is used.
Code decays when it is "more difficult to change then it should be."
This excessive difficulty is reflected in three factors:
programmer cost, time to make the change, and quality of the software
after the change.
The last two factors are constrained by deadlines and quality standards,
so in the end code decay is reflected in excessive programmer cost
to produce code of a given quality by a certain deadline. (102)
Empirical findings include:
(1) Increase over time in the number of files touched per change to the
code; (2) The decline in modularity of a subsystem of the code;
as measured by changes touching multiple modules; (3) Contributions
of several factors (notably, frequency and recency of change) to
fault rates in modules of code;
and (4) That span and size of changes are important predictors
(at the feature level) of the effort
to implement a change. (110)
Includes a list of "causes of code decay" and "risk factors for code decay" (103)
The notions of
"fatal code decay" and "perfective maintenance" to prevent code
decay are also mentioned.
Would functional Erlang fare any better?
Posted to Software-Eng by jon fernquest on 8/8/02; 1:41:09 AM
|
Does Code Decay?
