Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Re: Debug Driven Design/Development - Why?

swatts
Active Participant

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

 

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Comments
Bob_Schor
Knight of NI

I am definitely interested!  I've had the experience of "making a small change" in working code and having Disaster strike, requiring an order of magnitude more time to find/fix ...

 

Anonymous (please ignore the name at the top of this post ...)

Intaris
Proven Zealot

For the sake of clarity, are we differentiating between "debug" and "test" with regard to writing code?

Asking for a friend. 😉

swatts
Active Participant

I'm planning out part 2 and am quite pleased with it. All will become clear then I hope.

But in short debug and test are 2 different things. Test can help with debugging in this context. Whereas debugging is part of the process of writing software.

 

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Terry_ALE
Active Participant

@swatts wrote:

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

 

Without the big picture, I'm having a hard time following or participating. Is there a post where you cover the overall process?


Certified LabVIEW Architect, Certified Professional Instructor
ALE Consultants

Introduction to LabVIEW FPGA for RF, Radar, and Electronic Warfare Applications
swatts
Active Participant

Coming....

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

richardscheff
Member

I am very curios where you go with this.

My style is to break apart as many steps as possible.  It is not unique to any software development.  But we all get lazy from time to time and put two or three functions in a single VI.  

But I try as I might to get each function which can then be called individually. 

I usually create a few dozen empty cases and fill them.

Then during development I force all error reporting to alert location and error and stop execution.  

At early development I want to remove all possible errors before they can start.  Rather than try to handle them after the fact.

Of course there are some errors which are not errors and those are notices.  But that goes to handling. But where possible I will try my best to get notices to be absent.  

One comes to mind.  Communication reading data and expecting 100 bytes but only getting 50.  And then getting a timeout error.  So I can write the program to grab 10 bytes at a time.

Or read bytes at port before trying to read (when available).  

But when not available and you need to read 100 bytes at a time for efficiency.  It is better to get a timeout error.

I do not know if my style is the same as your debug style.  And so I am curious to find out.  And I can not see how anybody could write software without doing it that way, unless they knew exactly every function before they started.

Or maybe you have a different approach and I am keen to learn it.

 

 

 

 

 

 

swatts
Active Participant

I also think it's about what is important and categorising it.

 

The next article will be about specific things we do, purely with debugging in mind and I'm planning a final article about our debugging process. I'm going to follow an issue through our tracking system from report to fixed and released.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Taggart
Active Participant

I tend to view testing as verifying that the software does something and debugging as figuring out why it didn't do that something. Related yet different.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
swatts
Active Participant

I'm going to push it a little further than that, I view debugging as also part of design discovery..

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

richardscheff
Member

I am curious, where do you put your diagnostic tools for your developments?  I find in the end it is best to keep everything in the software under some protected tabs.  It helps me get through validation processes, and it usually helps in the future when something breaks. 

 

the only downside is extra cases that make development less readable, because when all is said and done I might have 50+ cases on a small project that would only need 10 -20.

If there is a better technique I am interested.

swatts
Active Participant

Next blog describes what I do (and a bit of what Joerg does). My method is a pretty light touch.

Then the discussion will be most interesting with regard to what other people do.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Enrique.Noe
Member

Whenever I found myself buying or interacting with tech stuff, I like explanatory things, for example, a printer, I prefer the one that explains with clarity which color is empty or if the paper sheets are stuck, there are other types that they are a torture, lot of buttons, complicated configuration, a lot of procedures, etc., I have the same preferences about software, I prefer the path that it is easy for me to find what went wrong, and where to fix it, instead the path that adds another problem to my existence.

 

Waiting for the next episode Steve!

Terry_ALE
Active Participant

I do not understand why a new term "Debug Driven Design" is being put forth.  Is there any other kind of design?

 


Certified LabVIEW Architect, Certified Professional Instructor
ALE Consultants

Introduction to LabVIEW FPGA for RF, Radar, and Electronic Warfare Applications
Dhakkan
Member

The moment I skimmed through Steve's article, I had the same question as Terry_ALE's first statement. Inspired by the actual question, I just looked up a search and found this compilation in Medium.

 

I just follow rODD - recursively Odd Design and Development. (The 'r' was just a flourish a la Apple's 'i'.)

 

swatts
Active Participant

That's a good question.

A copy of a reply in a LinkedIn question covers some of my thoughts, as it was being used to comment on other frameworks and that wasn't the point really.

 

"I only really like to talk on specific areas of design to concentrate on. So the point of DDD is making debugging one of the primary considerations when designing a system. This doesn't exclude any particular framework, more that it is a consideration when using that framework. So what can I put in place to make debugging easier in my AF project, what disciplines can I follow, how do make visualisation, navigation easier etc etc."

 

The idea is to make it a first class citizen, whereas in my experience I've not seen that... in fact it's the first thing that's been sacrificed.

 

Obviously I get called in to rescue projects quite often, and this will skew my view of the world.

 

I also quite like changing the direction of view. Previous to this I would concentrate on design specifics like cohesion and coupling, and one of the benefits would be ease of debugging. But what if you concentrate on ease of debugging and one of the benefits becomes good cohesion. For a lot of people that might be an easier thing to get your head around.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Terry_ALE
Active Participant

https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/Design-Priorities/ba-p/3559289 has a good list of priorities and debugging is mentioned

 

 


Certified LabVIEW Architect, Certified Professional Instructor
ALE Consultants

Introduction to LabVIEW FPGA for RF, Radar, and Electronic Warfare Applications
swatts
Active Participant

Which makes me think about what happens if you prioritise a particular aspect and how that would affect your designs. 

 

The point of the table was to pick a limited number of things and then target your design to suit (which is a point I've been hammering for a few years now)

 

If I can be bothered I could try that as an exercise.

 

Thanks for your input Terry, it's got me thinking.....

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile