Module 5: Problem Solving: Case Studies
These are synthetic teaching scenarios, not documented incidents from the linked sources. Source anchors provide background only. They teach the habit of slowing down: define the problem, choose a representation, test small cases, then generalize.
Case Study 1: Solving the Wrong Problem
Scenario: A learner is asked to reduce duplicate support tickets. They immediately write code to merge tickets, but the real issue is duplicate ticket creation from a webhook retry.
Source anchor: MIT Mathematics for Computer Science.
Module concepts:
- problem framing
- assumptions
- root cause
- evidence gathering
Wrong Approach
Start implementing the first solution that sounds related.
Better Approach
Restate the problem, list assumptions, collect examples, and separate symptom from cause. Only choose an algorithm after the model matches reality.
Tradeoff Table
| Choice | Gain | Cost |
|---|---|---|
| Jump to solution | Feels productive | May solve wrong problem |
| Problem restatement | Clarifies target | Slower start |
| Evidence-first approach | Better fit | Requires data access |
Failure Mode
The merge job hides duplicates but the webhook continues creating them.
Required Artifact
Write a problem brief with symptom, suspected cause, evidence needed, non-goals, and chosen representation.
Project / Capstone Connection
Use this brief before later project fixes so you solve the operating problem instead of the first symptom that looks actionable.
Case Study 2: Small Cases Before General Formula
Scenario: A learner must count possible password patterns under constraints. They try to derive a formula immediately and double-count cases.
Source anchor: MIT Mathematics for Computer Science.
Module concepts:
- small cases
- pattern discovery
- double counting
- validation
Wrong Approach
Write the first formula that matches one example.
Better Approach
Enumerate small cases, mark overlaps, then generalize. Verify the formula against brute force for small inputs before trusting it on large inputs.
Tradeoff Table
| Choice | Gain | Cost |
|---|---|---|
| Formula first | Fast if right | Easy to double-count |
| Small cases | Reveals structure | Takes patience |
| Brute-force checker | Catches mistakes | Limited to small inputs |
Failure Mode
The answer is off by a factor because invalid overlaps were counted twice.
Required Artifact
Produce a small-case table, proposed formula, and brute-force verification plan.
Project / Capstone Connection
Carry this small-case and brute-force pattern into later algorithm and systems debugging where intuition alone is too fragile.
Case Study 3: Debugging by Hypothesis
Scenario: A sorting exercise fails only on duplicate values. The learner changes random lines until the sample passes, then another case breaks.
Source anchor: Google Python Style Guide, connected to readable, testable debugging.
Module concepts:
- hypothesis-driven debugging
- minimal failing case
- invariants
- regression tests
Wrong Approach
Patch code until the visible output matches the sample.
Better Approach
Shrink the input to the smallest failing duplicate case, state the suspected invariant violation, test the hypothesis, and keep the regression test.
Tradeoff Table
| Choice | Gain | Cost |
|---|---|---|
| Random edits | May pass one sample | Creates new bugs |
| Minimal case | Clear signal | Requires reduction effort |
| Invariant check | Finds cause | Needs conceptual clarity |
Failure Mode
The sample passes but the bug remains for a neighboring input.
Required Artifact
Write a debugging log with failing input, hypothesis, experiment, result, fix, and regression test.
Project / Capstone Connection
Use this debugging log format in later incident reviews and project postmortems so fixes remain tied to evidence and regression protection.
Source Map
| Source | Use it for |
|---|---|
| MIT Mathematics for Computer Science | Problem framing, proof habits, and small-case reasoning. |
| Google Python Style Guide | Readable and testable debugging artifacts. |