How to deal with LabVIEW Spaghetti Code

Are you finding yourself saying “I have to make another change to this code and it’s so painful I want to gouge my eyes out!”? Or “My LabVIEW programmer left and no one can figure out what he did!”?

Sometimes referred to as “frankencode”. It’s a wiry mess, it has no architecture or modularity. It’s just bad LabVIEW code. It’s been dropped in your lap and now you have to deal with it.

We get it.

There’s a light at the end of that tunnel. You’ll want to know:

Do I really have spaghetti code or is this just a complex application?
Is it salvageable or do I need to start from scratch?
How does it get fixed?

Diagnose it – Do I actually have spaghetti code or is it just a complex application?

The first step is to start to get a sense of how bad this code really is. The items below will give you indicators to help you determine if you’ve got spaghetti code. The more of these items that are true, the more likely it is you’ve got some bad code.

More than ~2-3 nested structures (case, sequence, loops/event structures/disables). It’s common to have an outer structure for handling an upstream error condition and an inner structure to handle the case select or event options. Within the inner structure, it’s okay to have a 3rd structure to handle some small operations.
You’re wiring actually looks like someone dropped a bowl of spaghetti on the ground, or more likely, the wiring looks like a labyrinth/maze that can’t be won. Wires might be overlapping or positioned underneath objects.
Extreme use of local or global variables. If your block diagram starts with local variable nodes on one side and ends with local variables on the other side, or worse, mixed within your diagram. LabVIEW code doesn’t need any local variables. They allow race conditions, since LabVIEW is inherently parallel processing, and you don’t know which part of the code is writing/reading to/from the variable when.
A large block diagram: if your scroll bar is 1/10 (or smaller) the size of your screen. The exception to this is when you’ve got LabVIEW FPGA code, in which case, this may be okay.
There aren’t any subVIs.
It was the developers first project. Good coding in LabVIEW takes time to learn, even if the developer is overall a very capable person.
Wires flowing backwards (from right to left; with the exception of feedback nodes)
Default icons – the developer didn’t bother to create an icon for their subVI.
Not properly labeling controls and indicators on subVIs.
One loop where there should be several parallel loops
More than ~25 nodes.
Poor file structure – no discernable organization, all files in one folder, the use of “and” in file names, long, convoluted file names.

How bad is it? When is spaghetti code salvageable vs when you should start from scratch

It sucks to throw something away and start over, but sometimes the risks and effort involved in recovery and on-going maintenance justify it. Here are 3 questions to ask yourself to help decide whether you can fix it or need to start over:

Is there any existing information about how the code works? This could take the form of an overview doc, an operators manual, or even a person that knows how the code works.
Is there any modularity to the design at all? If so, there may be salvageable pieces if nothing else.
Can you find a semblance of an architecture to grab ahold of, or is it necessary to understand every piece of code to get what’s going on?

When you work with LabVIEW long enough and you’ve seen enough code, you get to a point where “you know it when you see it”. If you work for a US-based manufacturer or R&D lab and you’d like us to assess your code, you can reach out here.

General approach for dealing with LabVIEW spaghetti code

There are additional details of course, but here’s the general flow of fixing spaghetti code:

Reverse engineering

Review the existing documentation and interview someone who knows how the code works. This will help orient you, but without extensive documentation you’ll still have to crawl through the code because the devil’s in the details. And yet, even with extensive documentation, you might still need to rely on the code for the details if you don’t trust that the documentation reflects the actual code.

Re-write the code

Decide how much to re-use vs re-write. This involves diagnosing things like modularity, architecture, variable utilization, maintainability, and readability.

The code should be salvaged and/or re-written by a LabVIEW expert this time so that you don’t end up in a messy code situation again. That expert could be in-house or outsourced.

Acceptance testing / regression testing –

This phase is all about answering two questions:

How do we know when it works?
How do we know we didn’t break something?

The amount of modularity in the code drives the criteria for acceptance testing. If it is true spaghetti code, your acceptance test criteria is going to need to be more comprehensive because it will be difficult to know if a change in one location affected another part of the code. If there is some modularity, an argument can be made to reduce the scope of the acceptance testing to encompass only the areas impacted by the changes.

How to get help

Sometimes when you’re dealing with spaghetti code, you’re also dealing with an obsolete test system. If you need help with that, see Automated Test System Migration | Replacing Obsolete Test Systems.

Want someone to take this mess off your plate so you can get back to your real job?