Software maintenance costs and best practices

software maintenance costs

As the twenty-first century advances more than 50% of the global software industry is engaged in modifying existing applications rather than writing new applications. This fact by itself should not be a surprise, because whenever an industry has such a long period of product experience, the personnel who repair existing products tend to outnumber the personnel who build new products. 

What is software maintenance?

The term “software maintenance” is surprisingly ambiguous in the software context. Within a common use, it can contains about different 20 forms of changes to existing applications. The two most common meanings of the term maintenance include repairing and enhancing bugs or adding new functionality to existing software systems.

Although software enhancements and maintenance in the sense of defect repairs are usually funded in different ways and have quite different sets of activity patterns associated with them, many companies lump these contrasting software activities together for budgets and cost estimates.

Consider some of the basic differences between enhancements or adding new features to software applications and maintenance or defect repairs as shown in the following table:

Activity/ResourceEnhancements (New features)Maintenance (Defect repairs)
RequirementsFormalNone
SpecificationsFormalNone
InspectionsFormalNone
DocumentationFormalNone
New feature testingFormalNone
Regression testingFormalMinimal

Because the general topic of software maintenance includes so many different kinds of activities, some companies merely lump all forms of maintenance together. They also use gross metrics such as the overall percentage of annual software budgets devoted to all forms of maintenance summed together. 

Major maintenance topics

Although the use of the term software maintenance as a blanket input for dozens of update activities is not very precise, it is useful for overall studies of internal software activities. Before proceeding, let us consider 19 discrete topics that are often coupled together under the generic term “maintenance”, but which are actually quite different in many important respects:

  1. Major Enhancements: new features of > 20 function points
  2. Minor Enhancements: new features of < 5 function points
  3. Maintenance: repairing defects for goodwill
  4. Warranty repairs: repairing defects under formal contract
  5. Customer support: responding to client phone calls or problem reports
  6. Error-prone module removal: eliminating very troublesome code segments
  7. Mandatory changes: required or statutory changes
  8. Complexity analysis: quantifying control flow using complexity metrics
  9. Code restructuring: reducing Cyclomatic and essential complexity
  10. Optimization: increasing performance or throughput
  11. Migration: moving software from one platform to another
  12. Conversion: Changing the interface or file structure
  13. Reverse engineering: extracting latent design information from code
  14. Re-engineering: transforming legacy application to client-server form
  15. Dead code removal: removing segments no longer utilized
  16. Inactive application elimination: archiving unused software
  17. Internationalization: modifying software for international use
  18. Retirement: withdrawing an application from active service
  19. Field service: sending maintenance members to client locations.

Although the 19 maintenance topics are different in many respects, they all have one common feature that makes a group discussion possible – they all involve modifying an existing application rather than starting from scratch with a new application. Although they have different reasons for being carried out, it often happens that several of them take place concurrently. For example, enhancements and defect repairs are very common in the same release of an evolving application. There are also common sequences or patterns to these modification activities. Reverse engineering often precedes re-engineering and the two occur so often together as to almost comprise a linked set. 

Small Maintenance Projects and Metrics

There are several difficulties in closely examining software maintenance costs. One of these difficulties is the fact that maintenance tasks are often outsourced to development personnel who dovetail development and maintenance when necessary. This practice makes it difficult to distinguish maintenance costs from development costs since programmers are often quite careless when tracking the time spent. Another significant problem is the fact that much of software maintenance consists of making very small changes to software applications. Quite a few fixes can involve fixing a single line of code. Adding minor new functionality, such as a new line element on a screen, may require less than 50 LLC statements. These small changes are below the effective lower bound for counting function point metrics.

If the project lasts a working day consisting of six hours, then at least the results can be expressed with common metrics. In this case, there would be about “6 staff hours per function position”. If the reciprocal metric “function points per employee month” is used and the month has 20 working days, the result would be “20 function points per employee month”.

Worst and Best Practices in Software Maintenance

Since maintaining aging legacy software is very labor intensive, it is very important to examine the best and most cost-effective methods available for dealing with the millions of applications that currently exist. The sets of best and worst practices are not symmetrical. For example, the practice that has the most positive impact on maintenance productivity is the use of trained maintenance professionals. However, the factor with the greatest negative impact is the presence of “failure-prone modules” in the application to be maintained.

At the top of the list of maintenance best practices should be the use of trained full-time maintenance specialists, rather than handing over maintenance tasks to untrained generalists. The positive impact of hiring maintenance specialists is one of the reasons why maintenance outsourcing is growing so rapidly. The maintenance productivity rates of some of the better maintenance outsourcing companies are roughly twice that of their clients before the outsourcing maintenance SLA. So even if the outsourcing provider’s costs are a bit higher, it can still make sense to be economical with profits.

A very common situation that often affects performance is the lack of proper maintenance tools, issue tracking software, general help desk software, change management software, test library software and so on. In general, it’s very easy to degrade maintenance efficiency and make it such a labor-intensive activity that few resources are left for development work.

Given the tremendous amount of effort being put into software maintenance now and in the future, it is evident that every organization should seek to adopt maintenance “best practices” and avoid maintenance “worst practices” in their full scale.