Software Assertions and Code Quality (2006)

I'm not an enthusiastic debugger.

The problem with bugs is that while 99% are easy to spot with a printf or two, 1% of the bugs can be very hard to find.

While coding, I will occasionally place an assertion at a place where a problem could be detected much earlier that it will be noticed otherwise. As an example, a bad index might be accessing memory in a location outside of the space allocated by a data structure. If this might happen due to a bug in the code, the program can run for some time without the illegal memory access being noticed. Errors like this may elude other tests and can produce unpredictable and inconsistent behavior. These are the spots I really like assertions that can stop the program (and open the debugger for investigation).

Early in my career I remember working with another developer for weeks to debug someone else's program. It was an assembly language program running on a process control computer doing real time control of a complex machine on an assembly line within a clean-room manufacturing area. It was physically impossible to slow down or break-point or single-step the program because it was running a complex machine with perhaps a dozen asynchronous physical activities going on. Furthermore, the machine had no I/O devices meant for human interaction attached to it. This required extreme measures to figure out. We had to write a program on another, different architecture computer that could use a direct memory access interface to observe the memory of the program being debugged.