Successful Software Maintenance

The Institute of Electrical and Electronics Engineers (IEEE) describes software maintenance as the modification of software after delivery to the user. The reasons for these changes include correcting faults, improving performance, and adapting the software to changes in requirements. All software requires maintenance, even when the software, its operating environment, and its requirements are completely stable. Minimizing maintenance costs becomes more important as the software’s complexity increases since they often exceed the initial cost of developing the software.

Overview

Software engineers often compare software maintenance to car maintenance. A car requires certain changes that should be performed at regular intervals such as changing the oil and aligning the tires. Major changes like rebuilding an engine are also necessary to ensure the car’s optimal performance once it reaches a certain mileage.

The need for maintenance on a car is easy to understand because physical objects wear down as you use them. However, this concept becomes hard to grasp when it comes to a digital product like software, which has no physical form. Code can’t wear out over time, so people who aren’t software engineers often assume that maintenance should be unnecessary for software, provided it’s written correctly in the first place.

However, the analogy between software and car maintenance isn’t perfect. Unlike a car, the components in software change frequently, so a change to one component can cause another component to fail. In this scenario, it would be as if a timing belt stopped working because the spark plugs were changed. Furthermore, the fundamental purpose of software often changes, which would be like converting a daily driver into a top-fuel dragster.

While equating the two types of maintenance can be helpful for understanding the basic need for maintenance, further explanation is needed to illustrate the need for proper planning and budgeting for software maintenance services.

Maintenance Types

Software engineers classify maintenance into the following four types:

• Corrective

• Adaptive

• Preventative

• Perfective

The figure below shows the preferred cycle for the maintenance process. However, out-of-cycle changes occur regularly, especially for corrective maintenance.

Figure 1: Maintenance Types

Corrective Maintenance

Corrective maintenance is a reactive modification of a software product to correct a known problem. This type of maintenance fixes defects in software, which often takes the form of quick updates performed on a recurring basis. Corrective maintenance is unlikely to have a negative impact on users, rarely complain about getting bugs fixed. It also provides a rapid return on investment (ROI) in improving user experience.

A corrective change can disrupt users on rare occasions. The common scenario of this type occurs when the defect in question has existed for a long period of time, allowing users to become accustomed to it. In this case, users typically adapt their behavior to accommodate the flaw. Once it’s fixed, users must then modify their behavior, resulting in negative responses to the effects. A corrective change can also frustrate users by making other bugs more obvious.

Software maintainers should make corrective changes quickly and often. This approach helps keep software functioning according to user expectations and can offset future problems.

Example

Assume for this example of corrective maintenance that developers have just launched their software. They learn that users are unable to log on to the application via their social media credentials due to a small defect in the applications authentication code that communicates with the social media platform. The quick update is able to restore login functionality from the social media site

Adaptive Maintenance

Adaptive maintenance is the modification of software to keep it usable after a change to its operating environment. Many factors can change an application’s environment, including new technical knowledge, hardware and security threats. These changes occur with greater frequency in most environments, so software that doesn’t receive regular adaptive maintenance quickly becomes outdated.

Adaptive changes primarily affect the software’s ability to run on a particular platform, which includes the operating system (OS), hardware and network. These changes tend to have a low impact on users since they focus on the software’s internal functioning. Integrating an existing application with new technology may result in a slight improvement in performance areas such as scalability and speed, but its overall functioning generally remains unaffected. Users are far more likely to notice when adaptive is completed, as this could prevent the software from working with the latest devices.

Example

In this example of adaptive maintenance, users have been logging on to the software from a social media platform with no problems for the past few days. Suddenly, all users are unable to log in from that site. An investigation by a software developer discovers that the social media site has changed the way it authenticates users with its application programming interface (API), meaning that the software must be modified to accommodate this change.

This scenario appears to be very similar to the one described in the corrective maintenance example, but the difference lies in the cause of the logon problem. In the corrective maintenance case, it was caused by an internal software defect. In this example of adaptive maintenance, the problem was due to an external third-party system.

Preventative Maintenance

Preventive maintenance is the modification of software to detect and correct software errors before they take effect. This type of maintenance is also commonly known as future proofing. It includes making the software easier to scale more easily in response to increased demand and fixing latent faults before they become operational faults.

Preventative maintenance is almost always completely transparent to the user, as it involves preparation rather than major changes. However, it can have a great impact later by facilitating highly visible changes in addition to increasing the software’s overall stability.

Example

Assume for this example of preventative maintenance that an application’s user base has been steadily increasing. However, a change to that application makes it much more useful to users, causing its user base to suddenly rise dramatically. The figure below shows this event in July 2012.

Figure 2: Growth in User Base

Developers aren’t sure if the application’s server can handle the increased load, but they do know that many users will abandon the product if the server crashes during this period of rapid growth. The organization avoids this outcome by adding more servers, while the developers make the software changes needed to take advantage of them. The application can now bring the additional servers online automatically when traffic reaches a certain level. This preventative maintenance is critical for the software’s continued success, even though it wasn’t needed when the software was first released.

Perfective Maintenance

Perfective maintenance improves the software’s functionality and usability. It includes refining and deleting existing features as well as adding new features, easily making it the largest category of software maintenance. In addition to changing an application’s functionality, perfective maintenance can also affect the way it looks. Changes to the software’s interface and user journey are thus part of perfective maintenance.

The scope and nature of perfective maintenance also makes this category the most likely to elicit protests from users. Changes to the backend code are noticeable by users, but changes to the front end are highly visible. Managing perfective maintenance therefore requires greater communication with users to mitigate this negative sentiment. Common techniques include product feedback, promoting the internal use of the software and providing accessible support.

Example

In this example of perfective maintenance, assume that users are consistently able to sign on to the application from social media sites. However, user feedback indicates that the first thing they want to see when they log in is their most recent activity, rather than their profile. This change is a type of perfective maintenance.

Concept Mapping

The figure below summarizes the reasons for the four types of software maintenance and the costs of not performing them:

Figure 3: Concept Map of the Four Maintenance Types
 

Maintenance Costs

There’s no standard process in the industry for calculating a maintenance budget or establishing a baseline for this process. Experts have attempted to predict these costs based on representative sampling of projects with similar complexity and scope. However, they don’t generally agree on what a maintenance budget should look like, even at a high level. For example, Jussi Koskinen estimates that maintenance costs account for more than 90 percent of the total development cost for software, while Stephen R. Scach cites a figure of 67 percent.

While a number of factors account for this large difference in findings, the main one is that the studies use different projects. The many variables in software development ensure that projects can’t be easily compared to each other. Furthermore, the distinction between development and maintenance is becoming increasingly less significant. Methodologies such as Agile and Lean UX both include the practice of continuing development, which may also be considered maintenance once the software is released to users. This paradigm shift requires a more delicate balance in budgeting among the four types of maintenance than in the traditional waterfall development model.

Third-party Services

Creating a maintenance budget on the basis of “average” projects is inviting failure since new conditions can cause it to change drastically. Furthermore, maintenance is about ensuring stable daily operations as much as it is about fixing bugs. In many cases, the solution to a problem requires changing something outside the software.

Third-party services allow developers to complete a project more quickly, but this dependency also increases maintenance costs. This cost increases with the software’s complexity, which developers must consider when creating code with third-party services. The app’s initial infrastructure is also a factor in determining its suitability for development with these services.

Examination of specific projects is an effective method of understanding the effect of third-party services on maintenance costs. The hypothetical projects in this comparison both have more than 20,000 users and have been in use for a year. Beyond that, the projects are quite different.

Product A

Product A is a social networking mobile app with geolocation capability. Its purpose is to connect people who like barbecue, allowing them to discuss topics such as barbecuing techniques and the latest barbecue restaurants in their area. Developers were able to build Product A extremely quickly through third-party integrations, which the app uses to do most of its work. This short development time has been critical to Product A’s early success in tapping into the rapidly growing barbecue market. Product A has many features to enhance user experience, but some of them see little use.

One of the most significant costs for Product A is that seemingly simple functionality often breaks due to updates to the third-party services it uses. This problem means that developers must constantly integrate updates to these services into their own applications. In one particular case, an update to a service used to notify users prevented them from knowing about a major barbecue competition in their area. To make matters worse, mobile OSs like Android and iOS typically require developers to perform multiple rounds of regression testing to ensure that the latest update didn’t create a bug in another function. Developers must then fix this broken functionality before they can apply the next update to the OS.

Product B

Product B is a web app that awards and tracks employee points for a particular company. Managers can log in to award points for employees for various accomplishments, such as completing a project on schedule. Team members can then redeem their points for qualifying prizes in a pool.

The developer created this application specifically for that company as part of a pilot program. It’s very simple, allowing the developer to host it internally by its own IT department. Furthermore, the software has almost no third-party dependencies, so the developer doesn’t have to worry about the application crashing due to updates of third-party services or the OS. Product B’s maintenance requirements are quite low compared to those of Product A.

Best Practices

Despite the challenges involved, software maintenance projects require a detailed plan that prioritizes the various maintenance types. While this process isn’t well standardized, it should take factors such as the software’s maturity, its purpose, and the development team into account. The following best practices show how to develop such a maintenance plan.

Maturity

An application’s maturity level and requirements for attaining high user satisfaction are critical for creating a maintenance budget. For example, software that hasn’t been released yet requires greater emphasis on corrective and perfective maintenance. This is because the software is too immature for developers to have resolved its defects, nor have users had the opportunity to firmly establish the behavior they want from the software. By the same token, adaptive and preventative maintenance becomes more important for more mature products.

Regardless of the application’s maturity level, greater volatility increases maintenance efforts. Furthermore, shorter development time also increases maintenance requirements due to the larger number of workarounds in the code. An increasingly common solution for this problem is to develop software with a lean methodology that firmly establishes an application’s desired complexity level during development.

Purpose

The developer’s level of understanding about the software’s purpose also has a profound effect on its maintenance plan. If developers are still gathering user feedback to determine what the software should do, perfective maintenance should have a greater priority. Consider the example of a startup company that has developed an application to sign up prospective customers. Perfecting that process would most likely be the highest priority for the developer.

On the other hand, preventative maintenance becomes a higher priority when system stability is more important than functionality. For example, a back-office system will probably want to focus on optimizing the database before anything else. These scenarios illustrate the importance of establishing priorities when developing a maintenance budget.

Team

The composition of the maintenance team is an issue that often fails to get the attention it deserves when planning software maintenance. In some cases, the organization using the application may have the technical expertise needed to maintain it, resulting in significant savings on maintenance.

Whether the maintenance team works for the user or developer, it needs to include subject matter experts (SMEs) who can provide a solid technical understanding of the software. These topics include the application’s architecture, business logic, and overall purpose. This level of familiarity over the software helps ensure a better maintenance plan and a more accurate budget. If you don’t already have at least one person like this on your team, you should hire outside experts and allow them the time needed to become familiar with your software.

Constraints

A maintenance plan must also address any constraints on maintenance. These could include an aggressive service level agreement (SLA) that requires the software to provide an unusually high level of uptime, which can limit the time available for some types of maintenance. Many developers also have a hard limit on what they can spend on maintenance. Regardless of the specific constraints, you need to discuss them before you can develop a maintenance plan.

Budget Checklist

This section provides more concrete information on developing a maintenance budget than the conceptual material in the previous material. The following checklist will aid in estimating the specific types of maintenance by ensuring you don’t omit major expenses from your plan.

• 1. Hosting. These include the fees for bandwidth, domain renewals, infrastructure, and SSL.

• 2. Preventative maintenance. The fees include periodic updates to plugins and security patches.

• 3. Changes in business logic or other rules. These changes may be mandated by law, which can change frequently.

• 4. Defect resolution. You can calculate the total cost of this maintenance by multiplying the number of defects by average cost of fixing each defect.

• 5. Rewriting code to improve maintainability.

• 6. Support for third-part dependencies.

• 7. Developer account fees. Both Android and iOS charge fees to developers for their respective OSs.

• 8. Software licenses.

• 9. Perfective updates for the user interface (UI) and user experience (UX).

• 10 SaaS account fees.

Additional Tips

The process of developing a maintenance budget is similar to that used to estimate the initial cost of the project, although maintenance has more variables than development. As with other cost estimates, this process is much more of an art than science. However, estimates that are more discrete and comprehensive also tend to be more accurate.

The most important tips for reducing maintenance costs include anticipating and planning for them during initial development. It’s also critical to consider your product’s volatility of purpose when estimating costs. Work with your software developer to ensure the budget is customized for that product. You should also strive to find the optimum balance between developing new features and fixing defects in existing code. Always try to identify as many specific maintenance tasks as possible.

Summary

The inevitable costs of maintaining software shouldn’t deter you from building a product by themselves. However, it’s essential to structure its early development in a way that keeps those costs manageable. Planning and preparation go a long way towards minimizing maintenance costs over the long term.