Fix and Iterate

Overview

Students debug their existing “Mood Radio” micro:bit projects using a systematic approach: observe the symptom, isolate the cause, fix, and retest. The lesson emphasizes iteration (improve after feedback) and students document bugs and fixes in an engineering log.

Learning intentions

Students will be able to:

• Identify and describe a bug using evidence from tests (what happened vs. what should have happened).
• Use a consistent debugging routine to isolate variables and test edge cases.
• Apply iteration by making one change at a time and retesting to confirm improvement.
• Interpret results to decide whether a fix solved the problem or revealed a new issue.

Success criteria

• I can write a clear “bug report” that includes steps to reproduce and the expected result.
• I can explain what I changed, why I changed it, and what test results show after the change.
• I can retest at least two edge cases and record whether the behavior matches the goal.
• I can give and use peer feedback using a structured checklist.

Curriculum links

• The Number System: add and subtract rational numbers on number line diagrams (used when interpreting “+ / −” signals in status displays or debug counters).
• The Number System: understand opposites as adding to 0 (used when checking for canceling logic such as “mute/unmute,” “on/off,” or opposite mood states).
• The Number System: understand division leading to rational numbers and sign rules (used when debugging any “score/volume” calculations that involve dividing by a constant).
• The Number System: understand multiplication extended to rational numbers and sign rules (used when debugging scaling factors for signal strength or thresholds in Mood Radio logic).

Lesson structure (45 minutes)

1. 0–5 min · Hook (Mood Radio fails). Teacher shows a short “wrong behavior” demo (e.g., radio responds backward or not at all) and asks, “What pattern do you notice?” Students do a quick think-write: symptom, suspected cause, and one question they have.

2. 5–12 min · Mini-lesson: the debugging routine. Teacher models a routine on the board:

• Step A: Define the expected behavior.
• Step B: Record the actual behavior (data, not guesses).
• Step C: Choose one likely variable to test.
• Step D: Change one thing, retest, and compare. Students repeat the routine with the demo using the same template.

3. 12–22 min · Debug Round 1 (teacher-guided isolation). Teacher circulates with a checklist and “one-change” rule. Students work in project pairs: pick the most frequent bug, run a test plan, and isolate one cause (examples: message formatting, thresholds, timer/loop timing, radio channel mismatch, or missing condition). They record in an engineering log: bug, evidence, change made, results.

4. 22–31 min · Edge-case testing sprint. Teacher prompts students to test beyond the “usual” case with two edge tests (choose two relevant to their design):

• boundary moods (lowest/highest value)
• rapid switching (spam inputs quickly)
• no signal / unexpected message format
• minimum/maximum volume or output threshold Students run the two edge tests, record outcomes, and write a one-sentence decision: “Fix confirmed” or “Fix incomplete.”

5. 31–39 min · Peer testing with usability checklist. Teacher explains peer feedback structure:

• What worked (one sentence)
• One problem to fix (describe symptom)
• One question (what to clarify)
• One suggestion for an additional test (edge case) Students swap roles: Tester reads the checklist and logs feedback; Builder answers and chooses the next fix target.

6. 39–45 min · Exit ticket: iteration reflection. Teacher collects a quick exit ticket with three prompts:

• Bug I found:
• Fix I made (one change):
• Retest result (solved / partially / not solved) + evidence.

Resources

• micro:bit devices, batteries/USB, and headphones/speakers or output materials
• student Mood Radio project code and printed/posted goal criteria
• engineering log template (paper or digital)
• structured peer usability checklist (paper or digital)
• timer for edge-case sprint
• teacher demo “broken” project (or prerecorded behavior)
• small whiteboards or scrap paper for symptom/expected statements

Assessment

• Teacher observation during Debug Round 1: students follow “expected vs actual” and choose one variable to test.
• Engineering log review: clarity of bug description, evidence recorded, and whether one-change retest is documented.
• Exit ticket: checks understanding of iteration and evidence-based decision-making.

Differentiation

• Support: provide sentence starters for logs (“When I press…, I expected…, but I observed…”). Offer a “variable menu” (radio channel, input threshold, loop timing, message type).
• Support for struggling students: require only one edge case for the first retest, then add a second if time allows.
• Extension: ask advanced pairs to debug a second bug after confirming the first, or to propose a test that could disprove their fix.
• EAL/SEN: use visuals for the routine (A-B-C-D cards), and allow oral recording of evidence before writing.