Random Ramblings on LabVIEW Design

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

Re: Complexity happens when you don't take care of the small things

Active Participant

Hello fellow LabVIEW Mierenneukers,

At the end of a hard week I fancied doing some writing.


Visiting the RAL User group the other day they did a round-table favourite tip type session. In it I tried to describe 1 or 2 things we do at SSDC. As I struggled to verbalise some of the things we do, it dawned on me that there is not 1 thing you can do to simplify your designs. In fact it's accumulation of small things and quite a lot of attention to detail.


This also backs up some of the points in my CLA summit presentation, where I talk about design effort being for human reward (i.e. computers don't really care about our design efforts, they strip everything down to 1s and 0s whatever).


So why bother with design at all if the computer doesn't care?

4Image.png4th Image on a google search of LABVIEW!!!!!

I address it in many articles but this is a nice one. But mainly you do it to be kind to future you (as Fab would put it).


I have tried to categorise the things we do and that is summarised below.



This is all about how much we can stuff in our brain and how it looks on our main tool for describing our solutions (the block diagram).


From icons, labelling of structures and naming to the application of abstractions - all of this is helping us to visualise our solution.





The importance of navigation around your solution shouldn't be underestimated. Here's a real-world example...


At a customer site the other week I was supporting a reasonably complex system that has been written pretty well in various LabVIEW styles (it was a product of quite a few programmers). On the whole it was pretty good, but there was one thing that infuriated me. I was trying to work out what it was doing and found a VI called getAnIns.vi. Had a look inside and all it did was pull about a cluster of AnIn classes and pass them out. All I was looking for was the numbers provided by the Analog Input card! In the end I had to search through the directories and luckily found a setAnIns.vi. All this in front of a customer who doesn't fully trust me (or know me). That kind of thing makes me VERY uncomfortable!. I should have been able to reference the AnIns and navigate to all things AnIn via the block diagram (ideally using the built in LabVIEW tools).


One small annoyance - now multiply x100, x1000 if the rest of the program is similarly designed.


High Cohesion is essential to navigation, bookmarks are damned useful too.


When debugging travelling from one part of the code to another related part should be small in distance or quick in speed. Leaving the block diagram counts as 2 steps in this process IMO. There's some great research that could be done on this!



I did a whole presentation on this! The main takeaway is separating code that cannot run independently from code that can. Carrier Code and Functional Code are the terms I quite like.

LabVIEW is brilliant at interactively telling you what is happening at the VI level, it's a shame to lose that advantage in your designs.


Sadly then I can't offer you a nice silver bullet to cure your code of complexity, just hard graft, attention to detail and experience. Maybe these are the silver bullets?

Lots of Love






Active Participant



after listening to Jon and you at last NI Week, I made a last-minute change to my own presentation, which was about various processes and tools one should supposedly be using: I added the word "Lite" to the original title "Best Practices". I felt that "Best Practices Lite" nicely summed up my message, which was "don't shy away from processes and tools because they seem too complex or too difficult - just do a little bit, start small, and see how that works for you". 


Is this a similar thing you're saying? Stop waiting for the silver bullet, and start doing all the small things? Because if you do, all these small things might actually add up to something that's close to a silver bullet?

Joerg Hampel | CLA, LabVIEW Champion, DQMH Trusted Advisor
hampel-soft.com | ALArchitects.org | GDevCon.com | DSH-Workshops.com | bit.ly/WUELUG
Active Participant

It's related because I think the same applies to process.

But I was trying to address the "one" thing that will makes complex software simple. This is the essential ambition for all design effort IMO. My conclusion is that there isn't "one" thing, but a myriad of small decisions.


This is an excellent point tho'!

"Stop waiting for the silver bullet, and start doing all the small things? Because if you do, all these small things might actually add up to something that's close to a silver bullet?"

Active Participant

After listening to Jon McBee and Dimitry at NiWeek last year, I've become a huge fan of refactoring... When I find those little annoyances like your anin example, I immediately refactor them...

Sam Taggart
CLA, CPI, LabVIEW Champion
DQMH Trusted Advisor
Active Participant

In theory I agree, in practice it's easier said than done when you are presented with a liability of $$$$$$$s if something you change cocks up.


Active Participant

It also depends on how much a of  house of cards the original code is...  If it's fairly modular it is a lot easier to refactor, especially if you don't cross the boundaries of the module...

Sam Taggart
CLA, CPI, LabVIEW Champion
DQMH Trusted Advisor
Active Participant

I was mulling this exact point after I replied to you, I think it's related to the inherent complexity of the task too. I'm on a fixed budget and target time too. All considerations.

Active Participant

Yeah at the moment I usually do hourly, so I roll it right in.


Also depends on if you do unit testing. If you do unit testing, then it makes it much simpler to refactor.  If the tests pass before and after your change then you can have some confidence in it.


Unfortunately usually when I want to refactor something it's because it's not modular and well-written to begin with.


I've been reading this book lately so it's kind of at the front of my mind:


Sam Taggart
CLA, CPI, LabVIEW Champion
DQMH Trusted Advisor
Active Participant

I agree that there is no single bullet to avoid unnecessary complexity in programs. 

But, if we had to come up with one, it would be:


@swatts@Steve wrote:


In fact it's accumulation of small things and quite a lot of attention to detail.


Now the question is how to get to that list of small things and how to help team members who do not have inherent attention to detail.


These are the things that we have done to ensure those little things are addressed in our projects:


  1. Create a project template, module templates, and tools that encourage the developer to follow the same style as the rest of the team (see DQMH as an example Smiley Wink, of course, your LabVIEW Component Builder would be a great example too). Ensure early on the project that the team member did use one of the templates and is not trying to reinvent the wheel.
  2. When we find something that annoys us during code reviews, we check if it is already in our style guidelines or our DQMH Best Practices. If it is not and it makes sense to add it, we add it.  
  3. If non-compliance can be found via VI Analyzer tests and it makes sense to create a custom test, then we create a custom test. Even if the developer does not run VI Analyzer tests, it is part of our process to run them before building or releasing code to customers.


Wait, it is starting to sound like another possible silver bullet would be to have a better software engineering process! 


That leads to what Joerg said, it is hard to go from no process to a full-blown process. So, pick a couple of things to try, check frequently with your team what is working, what needs improvement and create from there the process that works for your team. 


Of course, none of this helps when we are in a situation similar to yours, where we have to add features to an existing application. All we can do in that case is to try to implement as much as we can following our process and good practices on the code that we will add. This is another reason we created DQMH, we can create a testable stand-alone DQMH module, then add it back to the existing application. If we cannot get rid of the spaghetti code, at least we can start adding well-defined meatballs to it Smiley Wink 


Steve, thanks, when I read your articles, I think more about what works and what we can still improve. 


Happy wiring,


Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Active Participant

I'm a big believer in taking small steps, so perhaps we need a magazine full of silver bullets!