Software Maintenance and Evolution
Most software cost lives after first release. Know the maintenance categories: corrective (fix defects), adaptive (respond to environment change - new OS, new regulation), perfective (improve performance or maintainability, add enhancements), and preventive (reduce future deterioration, e.g., refactoring, adding tests). Questions love to test classification: a change to support a new database version is adaptive, not corrective.
Understand software aging and technical debt - the metaphor for shortcuts that accrue interest as slower change and higher defect rates. Distinguish deliberate/prudent debt (a conscious trade-off) from inadvertent/reckless debt. Grasp legacy system challenges: missing documentation, obsolete technology, high business value, and the strangler approach of incrementally wrapping and replacing rather than big-bang rewrites. Know impact analysis and regression testing as the twin safeguards of safe change, and reengineering (restructuring) versus reverse engineering (recovering design) versus forward engineering (rebuilding).
Traps: labeling any change "corrective" because it followed a complaint; assuming a rewrite is always better than incremental evolution (rewrites lose embedded knowledge and carry huge risk); and ignoring that preventive maintenance pays off later but is easiest to cut under pressure. Also watch for maintenance performed without regression tests - the classic path to cascading breakage.
Rule of thumb: before changing legacy code, write a characterization test that pins current behavior - even buggy behavior - so you can detect unintended change.
Worked example: A bank must move an old COBOL batch system to a modern platform. Rather than a full rewrite, the team wraps each function behind a service interface, replaces them one at a time, and retires the old code when empty - the strangler pattern, balancing risk and progress.