[2] One twenty-first century innovation has been companies deliberately releasing incomplete software and planning to finish it post-release.
The maintenance team will require additional resources for the first year after release, both for technical support and fixing defects left over from development.
At some point, the company may decide that it is no longer profitable to make functional improvements, and restrict support to bug fixing and emergency updates.
[13] This may require input from multiple departments; for example, the marketing team can help evaluate whether the change is expected to bring more business.
[19] Following coding conventions such as using clear function and variable names that correspond to their purpose makes understanding easier.
On the one hand, it is common to haphazardly apply a quick fix without being granted enough time to update the code documentation.
Open-source software projects instead rely on mailing lists and a large number of contributors to understand the code base and fix bugs efficiently.
[27] An additional problem with maintenance is that nearly every change to code will introduce new bugs or unexpected ripple effects, which require another round of fixes.
[2] Testing can consume the majority of maintenance resource for safety-critical code, due to the need to revalidate the entire software if any changes are made.
[29] The key purpose of software maintenance is ensuring that the product continues to meet usability requirements.
[36] Technical debt is incurred when programmers, often out of laziness or urgency to meet a deadline, choose quick and dirty solutions rather than build maintainability into their code.
[38] One important aspect is having a large amount of automated software tests that can detect if existing functionality is compromised by a change.
[31] A challenge with maintainability is that many software engineering courses do not emphasize it, and give out one-and-done assignments that have clear and unchanging specifications.
[42] The task is often assigned to temporary workers or lesser-skilled staff,[2][43] although maintenance engineers are also typically older than developers, partly because they must be familiar with outdated technologies.
[47] Downsides of offshoring include communication barriers in the form of such factors as time zone and organizational disjunction and cultural differences.
Often legacy systems are written in obsolete programming languages, lack documentation, have a deteriorating structure after years of changes, and depend on experts to keep it operational.
[58] As of 2020[update], automated solutions for code refactoring to reduce maintenance effort are an active area of research,[59] as is machine-learning enhanced maintainability assessment.