Phase 2 of 5  ·  Design & Modeling
Week 09 / 20   ·   Ch 9

Software
Evolution

"Why companies still maintain 20-year-old systems"

📚 Ch 9 — Software Evolution🏚️ Legacy Systems🔧 3 Maintenance Types⏱ ~20 min read

🔍Concept Deep Dives

Click each concept to expand — real examples, diagrams, pros & cons.

🔄

Software Evolution Process

Change requests → Impact analysis → Release planning → Change implementation → System release.
⌄

When to Use

Every change to a production system should go through this process.

Real-World Example

A bug report in production → impact analysis → hotfix release → regression test → deploy. This IS the evolution process.

✓ Advantages

  • Controlled change reduces risk
  • Impact analysis prevents surprises
  • Audit trail

⚠ Watch Out

  • Overhead for small changes
  • Slows down emergency fixes if too rigid
Change Request ↓ Impact Analysis ↓ Release Planning ↓ Change Implementation ↓ System Testing ↓ Deployment
🏚️

Legacy Systems

Old systems still in use. Often critical to business. COBOL banking, airline reservation systems, government systems.
⌄

When to Use

When the system still provides business value despite being technically outdated.

Real-World Example

US banks still run COBOL for core transactions. FAA air traffic control. NYSE core systems. Replacing them is too risky.

✓ Advantages

  • Battle-tested reliability
  • Deep business logic encoded over decades
  • Known behavior

⚠ Watch Out

  • Hard to find developers
  • Expensive to maintain
  • Integration with modern systems is painful
Legacy Assessment: Business Value: High/Low System Quality: High/Low → Low value + Low quality = Scrap → High value + Low quality = Reengineer → Low value + High quality = Replace → High value + High quality = Maintain
🔧

3 Types of Maintenance

Corrective (fix bugs), Adaptive (new environment), Perfective (new features/improvements).
⌄

When to Use

Understanding what type of change you're making helps estimate effort and risk.

Real-World Example

Corrective: fix login bug. Adaptive: update for iOS 18. Perfective: add dark mode or improve search algorithm.

✓ Advantages

  • Classifying maintenance helps prioritize
  • Perfective = most value
  • Corrective = urgent

⚠ Watch Out

  • Boundaries blur in practice
  • Perfective maintenance can destabilize systems
Corrective ~21%: Fix defects Adaptive ~25%: Environment changes Perfective ~50%: New features + improvements Preventive ~4%: Refactoring, documentation
🔨

Refactoring

Improving code structure without changing external behavior. Fights technical debt.
⌄

When to Use

Continuously — 'Boy Scout Rule': leave code cleaner than you found it.

Real-World Example

Extracting a 200-line function into 5 well-named functions. Replacing a magic number with a named constant.

✓ Advantages

  • Reduces tech debt
  • Improves maintainability
  • Makes future changes cheaper

⚠ Watch Out

  • Risk of introducing bugs
  • Time investment upfront
  • Hard to justify to non-technical managers
Before: processOrder() – 200 lines, 8 responsibilities After: validateOrder() calculatePricing() applyDiscounts() chargePayment() sendConfirmation() Same behavior, cleaner structure

📋Quick Reference

θ Ch 9 Cheat Sheet — Software Evolution
Evolution Process
Change request → Impact analysis → Release planning → Implementation → Test → Deploy.
Legacy System
Old, critical system. Often COBOL, mainframe. High business value, low technical quality.
Legacy Assessment
2x2: Business Value vs System Quality. Determines strategy: maintain, reengineer, replace, or scrap.
Corrective Maintenance
Fix bugs. ~21% of maintenance effort.
Adaptive Maintenance
Update for new OS, hardware, regulations. ~25% of effort.
Perfective Maintenance
New features + improvements. ~50% of effort — the most valuable.
Refactoring
Change code structure without changing behavior. Fights tech debt. 'Boy Scout Rule.'
θ
Sommerville's Key Points — Ch 9
Author's own summary from the end of the chapter.
  • 1Software evolution: software must change or it becomes less useful over time.
  • 2Evolution process: change requests → impact analysis → release planning → implementation → release.
  • 3Legacy systems: old systems that remain critical to business. Often expensive to replace.
  • 4Legacy system assessment: evaluate business value vs. system quality to decide strategy.
  • 53 types of maintenance: corrective (~21%), adaptive (~25%), perfective (~50%).
  • 6Refactoring: restructuring code without changing behavior. Essential for long-term health.
  • 7Technical debt: accumulated shortcuts that make future changes harder.

🧠Quiz — Test Yourself

Think through your answer first, then reveal.

Q1
Recall
Why don't companies just rewrite legacy systems from scratch?
Because it's extremely risky. The new system must replicate decades of encoded business logic, edge cases, and regulations — much of which is undocumented. Classic example: Netscape's rewrite of Navigator took 3 years and lost them the browser war. Joel Spolsky called this 'the single worst strategic mistake a software company can make.'
Q2
Apply
What are the 3 types of software maintenance? Which is most common?
Corrective (fix bugs ~21%), Adaptive (environment changes ~25%), Perfective (new features/improvements ~50%). Perfective is most common — teams spend most time improving and extending, not just fixing bugs.
Q3
Analyze
What is the 'Boy Scout Rule' in refactoring?
Leave the code cleaner than you found it. Even if you didn't create the mess, improve it slightly every time you touch it. Over time, this keeps technical debt from compounding. Named after the Boy Scout principle: 'Always leave the campground cleaner than you found it.'
Up Next → Week 10
Dependability and Security
What makes software trustworthy? 5 properties every engineer must know.
Continue → Week 10