4.case analysis.code.decay

8/12/2019 4.Case Analysis.code.Decay

1/40

Jan'04 (C) N.H. Madhavji 1

Case Analysis of Code Decay

Nazim H. Madhavji

Dept. of Computer ScienceUniversity of Western Ontario


2/40


Statement

A central feature of the evolution of largesoftware systems is that change:

which is necessary to add new functionality,accommodate new hardware, and repair faults

becomes increasingly difficult over time.


3/40


Background

In the paper entitled, Does Code Decay ? ..[Eick, Graves, Karr, Marron and Mockus, IEEE

Trans. on Soft. Eng., Vol. 27, No. 1, Jan. 2001]the authors examine change data from a large telephone switching system.

The authors find mixed, but on the whole persuasive, statistical evidence of code decay,which is corroborated by developers of the code.


4/40


Agenda

In these slides, we shall look not so much atthe technical details of code decay asmuch as some architectural issues inferred from their paper.


5/40


Some system details

Telephone switching system (U.S) 100 MLOC in total 20MLOC each release C/C++ code (+ proprietary state description

language) 50 major subsystems

5000 modules: One module contains many code files More than 10,000 developers have worked on the

system over 15+ years.


6/40


What is Code Decay?

Code is decayed if it is more difficult to change thanit should be , as reflected by three key responses:

1. COST of the change, which is effectively only the personnel cost for the developers who implementit,

2. INTERVAL to complete the change, the calendar/clock time required, and

3. QUALITY of the changed software.


7/40


However, note: - 1

Not all increase in difficulty results fromdecay: it is possible that the inherent difficulty

of the desired changes is increasing. Decay is distinct from the ability of the

software to meet requirements: Code can be

correct and still be decayed, if it isexcessively difficult to add new functionalityor make other changes.


8/40


9/40


However, note: - 3

Code can decay because of previouschanges to the software.

Thus, there are actionable means to prevent, retard, or remediate code decay.

A region of the code can also decay as theresult of changes elsewhere.


10/40


However, note: - 4

Finally, the harder to change than it shouldbe aspect of code decay, while central, is

elusive. Some code is simply inherently hard to change

and to attribute this to decay is misleading.

Therefore, in measuring code decay youneed to allow for such inherent complexity(perhaps due to domain complexity ).


11/40


However, note: - 5

Also, difficulty of change is a functionof the developer making the change.

Thus, developer know-how andexperience needs to be included in any

measure of code decay.


12/40


13/40


Code Decay & Architecture - 2

It can help determine parts of thesystem that are changing more rapidlythan the others.

OK, this is good for understanding

purposes, but we need to relate this toconcrete business concerns.


14/40


Code Decay & Architecture - 3

For example, it allows us to assess theimpact of such decay on specificquality attributes of the system: Is performance degrading? Is portability and resuability being affected? Is cost of system change increasing? Is security being compromised? Too many inter-element connections?


15/40


Causes of Code Decay

In a sense, change to code is the cause of decay. As change is necessary to continue increasing the

value of the software, a useful concept of a causemust allow change to be present or absent in a

project under active development. Causes of decay reflect the nature of the software

itself, as well as the organizational milieu withinwhich it is embedded.


16/40


Example Causes of decay - 1

1. Inappropriate architecture that does not supportthe changes or abstractions required of the

system. too messy architectural attributes: Coupling & cohesion issues Too sensitive to certain kinds of changes

E.g., overall performance drops dramatically when

changes made to data/object accesses (say within loops)to incorporate new features or support non-functional needs (e.g.,

platforms, inter-operability, performance enhancements,user-interface upgrades, etc.)


17/40



2. Violations of the original design principles ,which can force unanticipated changes

which may invalidate the original systemassumptions. Changes that match the original design tend to

be comparatively easy

while violations not only are difficult toimplement, but also can lead future changes to

be difficult as well.


18/40



For example, in switching systems, many of theoriginal system abstractions assume thatsubscriber phones remain in fixed locations.

Original design was based on principles in thecontext of fixed locations.

The changes required to support wireless phonesthat roam among cell sites were unanticipated by

the original system designers. Note that this cause can be difficult to distinguishfrom inappropriate architecture.


19/40



3. Imprecise requirements , which can prevent programmers from producing crisp code, cause

developers to make an excessive number ofchanges.4. Time pressure , which can lead programmers to

take shortcuts, write sloppy code, or make changeswithout understanding fully their impact on thesurrounding system.


20/40



5. Inadequate programming tools , i.e.,unavailability of computer-aided software

engineering (CASE) tools.6. Organizational environment , manifested,

for instance, in low morale, excessive

turnover, or inadequate communicationamong developers, all of which can producefrustration and sloppy work.


21/40



7. Programmer variability , i.e., programmerswho cannot understand or change delicate,

complex code written by their more skilledcolleagues.


22/40



7. Inadequate change processes , such as lackof a version control system or inability to

handle parallel changes This cause is particularly pertinent in today's

world of Web distribution of open sourcesoftware.


23/40



8. Bad project management may amplify theeffects of any of these causes.


24/40


25/40


Yet other Example Causes of decay - 10

9. Exogenous changes . Those changes impinging on the system from

outside the system, e.g.: New, end-user, requirements Organisational strategies, restructuring, takeovers,

mergers, etc. Government regulation changes

Intra- organisational stakeholders requirements Etc. All such changes can induce changes to software

code which, in turn, can cause decay.


26/40


Summary causes of code decay

All these causes can, in one way or another,affect architectural quality of a system.


27/40


Symptoms of code decay - 1

1. Excessively complex (bloated) code ismore complicated than it needs to be to

accomplish its task.2. A history of frequent changes, also known

as code churn, suggests prior repairs and

modifications. If change is inherentlyrisky, then churn signifies decay.


28/40



3. Code with a history of faults may bedecayed, not only because of having been

changed frequently, but also because faultfixes may not represent the highest quality

programming.


29/40



4. Widely dispersed changes are a symptomof decay because changes to well-

engineered, modularized code are local. This symptom produces clear scientific

evidence of code decay.

Note that widely dispersed (inter-element)changes are very likely to affect architectural properties of the system.


30/40



5. Numerous interfaces (i.e., entry points) are citedfrequently by developers when they describe

their intuitive definition of code decay. As the number of interfaces increases, increasing

attention must be directed to possible side-effects of changes in other sections in the code.

Clearly, this is of an architectural concern.

C b h


31/40


SeeSoft view of one Module ol o

ur r e pr e s e n t s

t h e a g e of

a s o ur c e

c o d e l i n

e .R a i n b o w c ol o

ur e d

ox

e s r e pr e s e n

t f r e q u e n t l y c h a n g

e d f i l e s ,

wh i l e b

ox

e s wi t h

a s i n gl

u e r e pr e s e n

t f i l e s

t h a t c h a n g e d l i t t l e s i n c e t h e i r

c r e a t i on

.Circled: code of relative stability .


32/40


Inference from the SeeSoft view - 1

Let us assume that a module denotes oneelement in the system architecture.

The module, thus, has an interface throughwhich other elements access the service ofthe element.

There are stable and changing parts of theelement (single and multi-colours).


33/40


Inference from the SeeSoft view - 2

Some questions that arise out of the view: Are the frequently changing parts related to the

interface? If so:

Are other (related) elements affected too? Which? Examine the changes to the interface. Are these parts recent or old code?

recent: seems like unstable (still unrefined?) old: seems like fundamentals are changing

If no: Changes are contained locally good.


34/40


1988: NicheWorks view of the modules

NicheWorks view of themodules in one subsystemusing change data through 1988to place modules which have

been changed at the same timeclose to one another .

Two clusters of modules areevident; a module within one ofthese clusters is often changedtogether with other modules inthe cluster but not withother modules.


35/40



NicheWorks view of themodules, this time incorporatingthe change history through 1989.

The 1988 clusters areconverging in on each other.

This suggests that the architecturethat was previously successful inseparating the functionality of thetwo clusters of modules is

breaking down.


36/40



The breakdown continuedand at the end of 1996there was no suggestion of

multiple clusters of modules.


37/40


Retarding Decay - 1

The, so called, Perfective maintenance (changes) is intended to improve the

developers ability to maintain the softwarewithout altering functionality or fixingfaults.

It has also been called maintenance for the sake of maintenance or reengineering .


38/40


Retarding Decay - 2

Another approach to retarding decay beinginvestigated currently is through developing

good policies that would guide in evolving thesystems. Such policies have roots in past experience and

empirical studies.

Tools would detect violations of these policies,during development, and provide appropriatefeedback.


39/40


Summary

Code decays over time. So does the overall system architecture.

Architectural visualisation show this. Systems must undergo restructuring from time to

time to improve the situation. Appropriate development policies can be used to

help retard decay. Dont know whether a system can live forever!


40/40

Ze End.

4.case analysis.code.decay

Documents