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?
4th 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?