• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Debug-able software

 
author
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
(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?

Thank you.

Rodrigo.



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.

  •  
    Ranch Hand
    Posts: 113
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks for the complete e interesting answer, Paul.
     
    You showed up just in time for the waffles! And this tiny ad:
    Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    reply
      Bookmark Topic Watch Topic
    • New Topic