As this article is work in progress, I'll be more than happy to personally answer any questions you may have.

Is your Lab's codebase poisoned?

As already outlined in my first post, LabVIEW is predestined for settings where scientists and engineers without proper grounding in software or LabVIEW training get to dabble in code that evolved through generations of interns, Bachelors and research assistants. The resulting code not only looks like but also performs like crap - but hey, it werks!

The worst case scenario for your internship might be where your team-lead did his Master's thesis and the code evolved over years without any significant software-engineering, refactoring or the most basic architecture in place. Its only obvious quality measure is that it actually "runs and does something" (just like the code in the picture) no matter the timing or other not so obvious limitations. You will waste three to six months of your precious lifetime without really learning anything - I mean except for maybe opening and closing a LabVIEW project and (sigh) dabbling in other people's bad code without breaking it (not trivial!)

The worst case scenario for your entire lab is that projects are stalled, delayed for months or research targets are never met because the very same team-lead (Dr.WhatchaMaCallHimWantsToSequenceYourDNA), even if he could fathom it, would never admit that the codebase is poisoned lest incriminating himself. The culprit is of course found easily: LabVIEW itself - since it's not a real programming language anyway, right!?

Sources of pathogenic agents

• Absence of a LabVIEW project structure
  If all you have is just a bunch of VIs in a folder chattering with each other, then you should beware of VIs linked across multiple folders along with instrument drivers and their DLLs/.NET-Packages in some other folder resulting in "the project" being married with the file system -> copying the project folder to a different place or even to a different machine will most likely break it.

• No architecture or design patterns whatsoever sprinkled with global/local variables or even property nodes, eventually resulting in Diagrams larger than your screen size that are hard to view and maintain.

• Age old uncertified LabVIEW instrument drivers or example VIs that were developed under exactly the same circumstances and the desparate attempt of integrating them in the described architectural void - and therefore creating a perfect shit-in / shit-out feedback loop.

Remedies

The good thing about LabVIEW being so graphic is that even those new to it easily can spot what's going on in the code. The above screenshot is iconic in the LabVIEW-scene and shows how easy LabVIEW makes it even for a CEO to spot infamous spaghetti-code even from a distance when visiting some lab.