Debugging .NET Applications … a power course (day 1/2)

  • Article

I attended day one of two of the “Debugging .NET Applications”, presented by my MVP colleague John Robbins, a master of debugging, a wizard of tools and a mountain range of experience and tips around debugging and testing. I signed up for the course as developers are expected to complete this course at some Clipart Illustration of a Full Classroom Of Students Sitting In Their School Desks And Listening To Their Professor As He Stands At A Chalkboardpoint and as I thought I may be able to learn a few new tricks. When I walked into the classroom I immediately noticed the ‘machine less” environment and thought “oh dear, how will this work and what will the next two days be like”.

First impressions are not always right, because this is one of the best courses I have attended to date and having started IT in the early 80’s, I have had to endure many different courses. In one day John has shared so much invaluable information on good code, analysis tools, Visual Studio and in essence equipping us to write code which we do not actually have to debug. In essence he is promoting the following:

  1. Duplicate bugs
  2. Describe bugs
  3. Assume bugs are yours
  4. Divide & Conquer … remove the noise
  5. Think creatively and use “bug talk”
  6. Leverage tools
  7. Start heavy debugging … only with a hypothesis, no gung-ho set breakpoint and wear off the enter next|step-over keys
  8. Verify bug fix
  9. Share & learn

Note that although we are on a debugging course, only one out of nine steps above, is focused on actual debugging.

The “bug talk” is a cool concept, which is similar to the “whiteboard chat” I have been promoting when you cannot solve a problem. Share the problem with your colleagues, with your dog, your cat, your TV … in fact whoever is willing to listen to your jabber and scribbling on a whiteboard. At some stage your mind will go “bing” and through discussing and talking through the problem on the whiteboard, you will see the answer. Bug talk is the same … if after a specific time you cannot fix the bug, call “Bug Talk” and discuss.

The other comments I enjoyed today and can relate to include:

  • Developers should code and test, delivering a working code base + unit harness to the testers, ensuring that developers flush out the silly mistakes and bugs, before asking the testers to test the business functionality, the scalability, performance, etc.
  • Minimum code coverage metric should be set at 85-90.
  • Good testing and especially code coverage, will result in better code quality
The statement of the day

“Anybody can write code, but only a professional can write maintainable bug!”

Tip of the day

Have you has a scenario where the application starts in debug mode, but no breakpoints seem to be hit? Your application crashes as you load to debug it? Your environment crashes trying to display the Watch windows? Or is Visual Studio behaving like a sycophantic application? Your .suo file may be corrupted. Record your debug settings and delete the .suo file … you will loose debug settings, but typically the VS environment is well behaved again afterwards.

In summary, I am flabbergasted after day one, thoroughly enjoying the course, learning tons and cannot wait for day two.

Well done John!