What Not To Do When Maintaining Software Applications

“Software maintenace: it’s a dirty job; but someone’s gotta do it”

Anonymous Software Maintainer, 2010.

Software maintenance is a task often off-loaded to junior developers, while in theory, the repercussions and difficulties associated with maintenance suggest it should be performed by the most capable of programmers. A skilled programmer can transform a project whereas a copy-pasta cowboy can only make problems worse.

The Legacy

Most applications are complex due to their functionality; for comprehension its advisable to try to avoid further legacy properties.

Legacy properties do not necessarily imply age, new applications may also be difficult to maintain.

There are four broad categories of maintenance [Lientz80]:

• Perfective maintenance – user defined changes (50%)
• Corrective maintenance – correction of errors (25%)
• Adaptive maintenance – due to changes within the environment (21%)
• Preventative maintenance – improve future maintainability (4%)

It can be seen that improving future maintainability, by tidying or improving the source-code is by the far the least frequent form of maintenance performed, most likely due to cost vs. short-term gain.

Size Matters

Assuming that 4,000,000 lines of code printed onto listing paper (that old-school, perforated, slightly green stuff – seems to be used by doctors…) would cover 1 mile.

The complete works of Shakespeare would take up 0.3 miles, whereas, the source code for Windows NT would take up 120 miles!

The average human can understand a maximum of 1/10th of a mile of code at once.

This is a problem because to truly understand the impact of change, it is imperative to understand the whole program, in order to understand, and be aware of, every point of change (perhaps program slicing would help?).

Code File Analysis

Code file analysis has shown that in most applications there is an increase in size and an increase in files over time. However, there will be some files that are highly maintained, and others that are hardly ever maintained.

These highly maintained files are prime candidates for preventative maintenance.

Plans become delocalised over time. What this means is that related chunks of code, may be broken up and spread through the code-base. This is a problem because making a change only understanding part of the code, and missing other related chunks leads to errors.

Call Analysis

Call analysis shows the interrelationships between code. Call analysis has shown that over time:

• new functions are added to code
• objects are created via a splitting process
• number of high-level functions per code sample increases with time
• call depth increases
• call graphs have specific traits that can be used to spot legacy tendencies
• increase in direct dominance relations

Call depth is an issue due to short term memory. The brain can only hold 7 +- 2 ‘items’ at once – or in this case, objects in the call depth/graph.

The specific, legacy indicating traits of the graph can be used to show complexity and hence justify the higher maintenance cost required to refactor and improve the code.

Data Analysis

Findings from data analysis have shown that localised data items become de-localised and that interfaces between modules become more complex [over time].

Traits of the Maintainer

Some maintainers can turn software around by developing code with reusable components. On other hand, ‘copy and paste’ reuse is a big problem.

Creating generic, reusable libraries cuts down on code [redundancy].

Implications

The implications are that it is better to batch change requests. If changes are grouped together they can be ‘designed’ into the system. Furthermore, it is important to select ‘good’ staff for maintenance.

Related posts:

1. An Introduction to Program Comprehension
2. An Introduction to Reverse Engineering
3. Software Evaluation – Surveys
4. Software Evaluation – Case Studies
5. Software Evaluation Introduction

Tagged as: evolution