Software maintenance

Software maintenance is the process of modifying computer programs after they have been delivered to users. While creating new software is a high-profile task, maintenance is the longest phase of the software life cycle. It can account for 80 to 90 percent of the total cost of a software product's life. The primary goal of maintenance is to preserve the usefulness of the software. This is often necessary because requirements change or errors are discovered.

Each maintenance task follows a specific process known as a change cycle. The cycle begins when a customer submits a change request. This request might ask for a bug fix or a new feature. A team then evaluates the request to see if it is feasible or too expensive. If they proceed, a programmer must study the existing code to understand its logic. This step is vital because changing code can cause unexpected ripple effects. After the modification, the team performs extensive testing. This includes regression testing to ensure that old functions still work correctly. Testing often consumes the largest portion of maintenance costs.

There are four distinct categories of maintenance defined by the ISO/IEC 14764 specification. Corrective maintenance involves fixing bugs or failures reported by users. Preventive maintenance is forward-looking and aims to stop problems before they occur. Adaptive maintenance modifies the software so it can function in a changing environment. Finally, perfective maintenance improves qualities like user experience or processing efficiency. Some estimates suggest that enhancement tasks, which include adaptive and perfective maintenance, make up 80 percent of all maintenance work.

Software maintenance has a long history in the computing industry. In the early 1970s, companies began forming dedicated engineering teams for support tasks. This allowed original development teams to focus on building new products. In 1972, R. G. Canning published a concept called the "Maintenance Iceberg." He argued that maintenance is an extension of development that includes the existing system as an input. Although technology has advanced, our fundamental understanding of these processes has changed little since the 1980s.

As software ages, it undergoes a predictable transition toward the end of its life. Initially, a product may receive many enhancements and new features based on user feedback. Over time, a company might decide that further improvements are no longer profitable. At this stage, support is restricted to essential bug fixes and emergency updates. The software may become difficult and expensive to change due to decaying architecture. This phenomenon is sometimes called software aging. Eventually, the product is withdrawn from the market and becomes known as a legacy system.

One major challenge in this field is the concept of maintainability. Maintainability is the ease with which software can be modified without breaking. Many organizations neglect this to meet tight deadlines, creating what is called technical debt. Technical debt occurs when programmers choose quick, messy solutions instead of building long-term stability. This can lead to code entropy, where the integrity of the system degrades over time. To combat this, engineers use a maintainability index to track the health of the code. This helps them decide if it is cheaper to rewrite the code than to keep changing it.

The workforce for software maintenance faces unique professional challenges. The job is often viewed as less rewarding than new development and typically pays less. Because maintenance teams are often different from the original developers, they may lack the incentive to write clean, easy-to-read code. Developers may also deliver incomplete software to avoid going over budget or time limits. Consequently, maintenance engineers often need extra resources to fix defects left over from the initial release. In 2008, approximately 900,000 of the 1.3 million software professionals in the United States were working in maintenance.