Debugging: Find and Fix Bugs Like a Detective

01What is a bug?

A bug is a mistake in a program that makes it do something you didn’t mean it to do. The robot turns the wrong way. The game gives you 5 points instead of 10. The app crashes when you press a button.

Debugging means finding a bug and fixing it. It’s detective work. Something went wrong, there are clues, and your job is to figure out exactly which line is guilty.

02Where the word “bug” comes from

You may have heard that the word “bug” comes from a real moth. That story is true, but it isn’t where the word started.

Engineers were already calling small faults in machines “bugs” in the 1800s. The inventor Thomas Edison used the word in his notebooks and letters in the 1870s. In a letter dated November 13, 1878, he wrote about the “little faults and difficulties” that show up when you build something new, and said they were called “Bugs.”¹

Then, on September 9, 1947, the team running the Harvard Mark II computer found an actual moth stuck in one of its relays. They taped it into their logbook with the note “First actual case of bug being found.” The joke worked because “bug” already meant a fault.²³

Grace Hopper, a mathematician and computer pioneer who later became a U.S. Navy rear admiral, worked on the Mark II. The Smithsonian, which now owns the logbook, says it probably wasn’t her logbook, but she and the rest of the team helped make the words “bug” and “debug” popular.² You can read the full moth story in Algorithms and Loops.

03Three kinds of bugs

Bugs come in different kinds, and each kind gives you different clues.

Syntax error

The code breaks the rules of the language, like a missing bracket or quote mark. The computer can’t understand it, so the program won’t even start. Usually you get an error message pointing near the problem.⁵

Runtime error

The code is written correctly, but something goes wrong while it runs, so it stops partway. Dividing by zero is a classic one. In Python, this kind of error is called an exception.⁵ When the robot bonks into a wall, that’s like a runtime error.

Logic error

The program runs all the way with no error message, but it gives the wrong result. These are the sneakiest, because the computer doesn’t know anything is wrong. Only you do.

04The debugging loop

Guessing randomly and changing things until it works can take forever, and it can add new bugs. Detectives follow a method. Here’s one that programmers use:

1. Reproduce it. Make the bug happen again, on purpose. If you can’t make it happen, you can’t check whether you fixed it.
2. Find where. Narrow it down. Which line was running when things went wrong? What was the last thing that worked?
3. Guess why. Make a guess (scientists call it a hypothesis) about what’s wrong: “I think the loop runs one time too few.”
4. Change one thing. Make one small fix that matches your guess.
5. Test again. Run it. Fixed? Great. Not fixed? Undo the change, and go back to step 2 with what you learned.

05Tracing: be the computer

Tracing means stepping through a program one line at a time, the way the computer does, and writing down what happens. It’s slow, but it’s the most reliable way to find a logic error.

This program is supposed to count down 3, 2, 1, then show “Liftoff!”:

1. count = 3
2. repeat 3 {
3. show count
4. count = count + 1
5. }
6. show "Liftoff!"

Let’s trace it. Keep a small table of what count holds after each pass:

Trace table for the countdown program

Pass	Shows	count after
1	3	4
2	4	5
3	5	6

It shows 3, 4, 5. The table points straight at line 4: count + 1 should be count - 1. That’s the power of tracing: you stop guessing and start seeing.

Bug Hunt Bot traces for you. As the robot moves, the block that’s running lights up, so you can see exactly where things go wrong.

06The usual suspects

Some bugs show up again and again. Learn their faces and you’ll spot them faster. Every one of these is a level in Bug Hunt Bot.

• Wrong turn: a left where you meant right, or + where you meant -.
• Off by one: a loop that runs one time too few or too many. This one is so common that programmers gave it a name: the off-by-one error.
• Missing step: you forgot a line. The robot walks right past the gem.
• Extra step: one line too many. The robot takes one more step and hits a wall.
• Wrong question: an if that checks the wrong condition (see Debugging a wrong condition).
• Wrong order: the right steps in the wrong order, like trying to pick up a gem before you reach it.

07Rubber duck debugging

Here’s a strange trick that really works: explain your code, line by line, out loud, to a rubber duck.

The idea comes from a 1999 book for programmers called The Pragmatic Programmer, by Andrew Hunt and David Thomas. They point out that when you explain step by step what your code is supposed to do, the problem often jumps out at you. The name comes from a programmer they knew who kept a small yellow rubber duck by his computer.⁴

Why does it work? When you explain out loud, you can’t skip steps. You have to say each thing the code does, and at some point you hear yourself say “and then it turns left…” and realize that’s not what you wanted.

No duck? A stuffed animal, a pet, or a patient friend works too.

08Bugs are normal

A bug doesn’t mean you’re bad at coding. It means you’re coding. Every programmer, from beginners to the people who build games and phone apps, spends a lot of time debugging.

• Read the error message. It’s a clue, not a scolding. It often tells you the line number.
• Test small pieces. Run your program after every few lines, not just at the end. Then a new bug can only be in the part you just wrote.
• Test the edges. Try the smallest, biggest, and in-between cases, like 0, 1, and exactly 100.
• Take a break. Fresh eyes spot things tired eyes miss.

Bug Hunt Bot, the robot game for this unit, is online at jugami.com/code-club/debugging/

10Spot the bug

Each program below has exactly one wrong line. Read the goal, trace the program with a real example, and find the guilty line, then click it.

12Talk About It

There are no single right answers here. Talk with a friend, your class, or a grown-up.

• Think of a time something you made didn’t work the first time: a recipe, a drawing, a LEGO build. How did you figure out what went wrong?
• Which kind of bug do you think is hardest to find: syntax, runtime, or logic? Why?
• Try rubber duck debugging on something that isn’t code, like the steps for tying a shoe. Did explaining it out loud change anything?
• Have you seen a bug in a real app or game? What do you think the programmers got wrong?
• Why might a team of programmers find bugs faster than one person working alone?

13Sources and credits

1. Thomas A. Edison Papers, Rutgers University, “Earliest Use of the Term ‘Bug’”: Edison’s 1870s use of “bug,” including his letter of 13 November 1878 (“‘Bugs’ as such little faults and difficulties are called”). Edison Papers: Edison and the bug
2. Smithsonian National Museum of American History, “Log Book With Computer Bug” (object 1994.0191.01): the 1947 Mark II moth; Edison’s 1870s usage; Grace Hopper’s role, and that the logbook was probably not hers. americanhistory.si.edu: Log Book With Computer Bug
3. Computer History Museum, “This Day in History: September 9, 1947, First Instance of Actual Computer Bug Being Found.” computerhistory.org: September 9
4. Andrew Hunt and David Thomas, The Pragmatic Programmer: From Journeyman to Master (Addison-Wesley, 1999), section “Rubber Ducking.”
5. Python documentation, “Errors and Exceptions” (tutorial): syntax errors, and exceptions (errors detected while a program runs), including dividing by zero. docs.python.org: Errors and Exceptions

Credits. Written for jugami.com by Grace, the Jugami Code Club teacher. The robot, game boards, favicon and share image are original art made in code (hand-written SVG) for this page. The countdown, welcome and score programs are made-up examples. Bug Hunt Bot runs only in your browser. It saves your best stars in this browser’s local storage and sends nothing anywhere.