Jake Worth

• debugging

Here’s a meme I saw this week:

Here we have a person debugging code, and they’re saying “My code doesn’t work. Let’s change nothing and run it again.”

This is something that I’ve done. It seems like a complete antipattern. But that’s not quite correct.

Repeatedly “running it again”, by loading a page, printing something, or starting an automated test, without making a prediction– yes, this is a bad practice. But sometimes trying something twice is a solid technique. The reason is that even if you don’t make a change, that doesn’t mean that nothing has changed.

What You Can Learn

Let’s say you run it again, and the issue doesn’t present itself on the second try. You haven’t fixed the bug. But what might you have learned?

• It’s a race condition! Sometimes the bug behavior wins, and sometimes it doesn’t.
• It’s time dependent! The bug happens at the top of the minute, but not thirty seconds into the minute, for instance.
• It only happens once! It’s idempotent– that’s useful information for debugging and accessing impact.
• It’s unpredictable! You’re going to have to do some work to reproduce it consistently.

Mindfully running it again means acknowledging that there are many variables at play in software, some of which change on their own. That’s useful to remember.

Even if the bug does happen twice, running it again means you get to see it again. Maybe you’ll notice something you didn’t the first time.

You can’t change nothing, so don’t hesitate to run it again.

What are your thoughts on this? Let me know!