home of the madduck/ blog/
Test-driven development

Lars, I strongly suggest test-driven development. It seems to preemptively do the most relevant of what the debugging rules you quote instruct you to do later. The principles:

  1. design your interface
  2. write tests that fail
  3. write the code to make the tests stop failing
  4. refactor
  5. lather, rinse, repeat

It's a philosophy that anticipates bugs and errors, yet it uses that very fact to guard against them.

Test-driven development has changed the way I (and many others, I learnt it while becoming a Plone developer) plan, design, think about, and implement code. And yet, it's really not far away from how you're already doing things. Really.

For C++ coders, I recommend libtut, which is elegant and non-intrusive.

PS: The definitive (and quite good) book on test-driven development by Kent Beck is only 200-something pages, so it's also in the domain of shorter books.

Update: sorry, liw, for making it sound like I assumed you had spent the last years in a cocoon or cave or curled up in a corner. I didn't intend to doubt that you know of TDD, just wanted to get that off my mind what your post put there.

And of course, I agree with you: TDD will not eliminate debugging. But it will make your debugging sessions a lot less frequent, even though the really long and painful ones are exactly those that it won't prevent...