Thursday, June 5, 2008

Possible Worlds and Software Bugs

When I write a program I try to think of what could go wrong. I then try to address these concerns with conditionals or try/catch blocks. This eliminates a lot of bugs early.

The method described above reminds me of an informal logic book which encourages the reader to imagine possible worlds to find counter examples in order to determine if an argument is valid. This is not rigorous but provides a gentle and intuitive introduction to logic. I don't know of a rigorous method of finding bugs in code and in some cases it's impossible so I like to use this method. Interesting that the non-bugginess of the software will be limited by the programmer's imagination [0].

User testing should flush out bugs that the programmer hasn't thought of and is important. However a programmer should take the time to try to anticipate the bugs first because:

  • You might see the bug directly as you write the code that caused it instead of waiting and hoping that a blind test on a larger scale flushes it out
  • It's easier to work on code that you just wrote which is fresh in your mind than old code which you need to relearn
  • User testing and reporting might not get a bug fixed until it's inconvenienced a lot of users
  • The bug may not get discovered until the software is run in a new domain
A friend of mine with a philosophy background said that he often finds it easy to spot bugs in other people's code. I wonder if any of this is related to what he does. I think studying philosophy helped make me a better programmer.

Footnote:
[0]
Which is probably limited by how tired the programmer is or the programmer's mood. Which in turn is probably limited by how much coffee or antidepressants the programmer has consumed.

No comments: