Daily Tip: Debug Early, Debug Often

Over the past month, online pundits have drawn attention to what they perceive as a growing number of flaws with Apple’s iOS and Mac OS X operating systems. Both platforms are buggier by the year, they argue, as a consequence of Apple’s laser focus on producing major updates every autumn or so.

If you’re a programmer or developer, bugs are a part of life. But when major bugs crop up in a shipped product, it can create huge problems: You need to build and release a patch, inform customers about the issue, handle the inevitable blowback from irate people—all while hoping that your efforts actually fix the bug without breaking anything else.

When writing code, make it a point to debug every line, which usually means running your work through a debugging tool (unless it’s a short program, nobody’s expecting you to go through your code line by line). Yes, that takes time, and no, you won’t catch everything—but if you can nail enough bugs that would’ve caused you some major problems in the real world, the effort will likely have been worth it. (And yes, you can also do a thorough bug-hunt without engaging in schedule-killing perfectionism.)

Upload Your ResumeEmployers want candidates like you. Upload your resume. Show them you’re awesome.

Related Articles

Image: Sven Hoppe/Shutterstock.com

2 Responses to “Daily Tip: Debug Early, Debug Often”

  1. A much better solution is TDD – test-driven development – where you create tests that prove the code you want to work then write code to make the tests work. The problem is that it takes planning to get good tests and most developers just want to jump in and write code. But at the very least you should write these regression tests before release.

  2. Kent Fredric

    How does this constitute advice?

    Can you elaborate on what you mean by “run your code through a debugger” means in this context?

    I have a debugger, I know how to use it. But “run your code through a debugger” requires you to have found input conditions that exhibit a flaw in the first place.

    Thus, running through a debugger is only useful if you have anomalous behaviour you’re trying to isolate.

    You’d be better off writing tests that ensure your code does what you think it does for a known set of inputs, and then doing coverage analysis to ensure branches and lines are executed.

    That will prove far more useful than a naïve single pass stepping through with a debugger, not only because it will ensure your code works, it will ensure the code works for the range of inputs.

    And not only that, it will demonstrate to other coders the range of inputs that are known to work.

    And when you have a bug, you find an input that triggers the condition, and you create a test that exemplifies that, and you add it to your codebase.

    Then you fix the bug, and re-run all your tests to make sure they passed.

    That is far more resilient than this amateur “Hope you didn’t break anything” approach.

    Yes, tests can’t guarantee that you wont break things that aren’t expressed by the tests. But its still far superior from a single person doing a single pass eye-balling the process, because after all, human perception is the leading cause of bugs. 😉