Debug Driven Design/Development - Why?

[swatts]

Hello Darlings,

I hope you are all keeping well during these trying times.

Debug Driven Design/Development is something I've been kicking around with my DSH friends for quite a while and at this weeks Virtual Coffee meeting with more LabVIEW friends we had a very interesting discussion about frameworks. A lot of great programmers use a particular framework and a comment made was that debugging can be difficult. For me this is an instant red flag, and that is because my programming style (and brain) relies on being able to debug easily. LabVIEW is great for debugging, it is one of the attractions for me and to diminish that is a large cost. Design is all about cost vs benefit, so your team or way of programming may find benefits it's all about trade-offs.

The follow-up question from Christian Butcher is 4 words that really started to make my brain tick.

"How do you debug?"

In the following articles I'm going to try and explain the whys and wherefores of that very simple, yet difficult question.

But first I'll try and talk about why it is so crucial to the way I work.

Why is debugging so important to my brain type?

I explored this in my talks about Immediacy, I have a cause and effect mind. Debugging is key to the design process for me because it helps me understand the design. I write a small bit of code and test it on a very small iteration. Usually from write to test in 5 minutes. I believe that this cycle time is important too.

The other thing is about ego, I never want to look stupid in front of a customer! This is absolutely crucial to my personality type and I have spend months (unpaid) improving difficult to debug software.

The payback for all this effort is that when a customer wants something changed, added or there has been an issue it can easily be sorted.

Key Concepts

Previously I've stated that Flexibility, Readability, Configurability and Maintainability are actually some of the most important aspects of a design for me. I actually think those terms could be grouped under the catch-all term "Easy to Debug". The key for "easy to debug" is "easy to understand".

A key part of being easy to understand is limiting where things are being done and good visualisation. So if something happens we know where to look and when the software is running we need good status information in real-time.

The next article will talk about techniques for making your designs easy to understand and I'm planning on a 3rd article on my debugging process.

Lots of Love