(moved here from Rodrigo's post in the "Welcome Paul Butcher" topic)
Rodrigo Bossini wrote:Hi all,
I'd like to ask a question to Paul:
During software development, what are some good strategies to make sure that you are making a "debugable" sotware?
When exactly do you start thinking about it? During software design? Only once you started coding?
Thanks for the question, Rodrigo.
Now this is a topic close to my heart. You won't be surprised to hear that a great deal of the book is devoted to this subject, in particular Chapter 9: The Ideal Debugging Environment and Chapter 10: Teach Your Software to Debug Itself.
The good news is that if you follow the normal principles of good software construction - separation of concerns, avoiding duplication, information hiding, and so on - as well as creating software that is well structured, easy to understand, and easy to modify, you will also create software that is easy to debug. There is no conflict between good design and debugging.
But you can also build a lot into the software in the first place, and I would suggest that this is something you think about all the way through the software design process. The kinds of things you can help with are:
Finding out about bugs in the first place.
Reproducing bugs once they've been reported.
Extracting relevant information from your software during diagnosis.
Ensuring that you don't introduce further bugs or regressions when you come to fix the problem.
Here are a few things that you can put in place to help with the above:
Automatic error reporting - e.g. that sends you an e-mail if there's an unhandled exception.
Automatic configuration and environment reporting - so you know exactly what state the software was in when a user encountered a bug.
Logging to help you trace exactly what a user did to invoke a bug, or exactly what the software is doing during diagnosis.
Automatic validation of preconditions, postconditions and invariants, helping you pinpoint the broken assumption once you've reproduced the bug.
Automatic regression tests to ensure that you don't break something else when you fix the bug.