Seeking advice on how to deal with inherited code

[crossrulz]

---

@LVIEWPQ wrote:

I have attached (one of many) the offending vi, and you'll notice the file name of Block 3 (engine derivative) Cell 2 (test cell) with BK (being the new hardware added in)

---

Yikes!  Two things immediately popped out to me:

1. Timed Loops do not belong in a Windows application.  They just add overhead you do not need for extremely little gain.  They could even be detrimental since they force everything in them to be single threaded.  And an Event Structure inside of a Timed Loop is the worst of these offenses.

2. Way too much code in a single VI.  Each of those loops should probably be their own VI and then have the GUI have a single loop that receives messages to update the GUI.

But the very first thing you need to do is get the code into a SCC system.  Talk to the software people in your company and use whatever they are using (most likely GIT).

[billko]

I have to state that, before you go mucking around inside the code, that you DEMAND that versioning software be installed.  The horrors of what could happen if there is none cannot be overstated.

[LVIEWPQ]

@crossrulz 

1. The company doesn't exactly have a software department. The nearest we have is a former secretary who orders peripherals for us. Those of us dealing with the labVIEW side of things are trying to rollout TSVN, but still not exactly sure this is the right way to do it. 

2. This is why I felt I needed to "Start again" I figured breaking everything down into their own VI's so that they are manageable and replicable made the most sense. 

[BertMcMahan]

I'll add another echo to the "Get SCC going!" train. You might not have a software department to do this, but you could put SVN on a Synology NAS and just have it sitting on your desk.

Or you could just use GitHub for very cheap (https://github.com/pricing) which I'd recommend over making your own repo.

Regarding your actual question: Do not attempt a from-scratch rewrite of this software. No, it's not built to be maintained, but it works right now. If someone is asking you to modify something, make a new program, etc. then you can ask for budget to do some rewrites.

My advice here is to take one bite at a time. My company has some legacy code written roughly 20 years ago in, IIRC, LabVIEW version 6. It has been "stable" for all of that time, despite being written and grown organically by at least 4 different developers of different skill levels.

My approach to that very old piece of software has been twofold:

1- When someone asks for a new feature or a bugfix, I create a time estimate. Initially, I would double my initial estimate since it was such a touchy codebase. Doubling my estimate gave me room in case I (inevitably) underestimated the complexity of the new feature. At first I never had time left over.

2- When I finished implementing the feature, if I had some more time I'd try to tidy up a section of the code using some of my remaining budget. Nothing huge, just organizing wires here, wrapping functionality in a subVI there, that sort of thing. Over the years, this approach has let me maintain a stable software program for production to use while slowly but surely refactoring out the worst parts of the code.

I know handling that Godzilla-sized VI sounds daunting, but I *guarantee* that rewriting from scratch will not get you where you want to go. You need to do it piecemeal, recognizing that ugly code that still works is, in fact, working code. It may pain you to keep it messy and it may seem overwhelming, but as they say- how do you eat an elephant? One byte at a time.

[Kyle97330]

---

@rolfk wrote:

It's a bit unwieldy and definitely grossly violates the "Diagram should be not bigger than your monitor" rule, but other than that I wouldn't consider it terribly bad.

Yes it looks definitely like a "green" application, meaning its organically grown development is visible in many places. But it's something that is actually workable.

---

Did you go back to the first frame in the stacked structure?  This part is giving me anxiety looking at it:

[rolfk]

---

@Kyle97330 wrote:

---

@rolfk wrote:

It's a bit unwieldy and definitely grossly violates the "Diagram should be not bigger than your monitor" rule, but other than that I wouldn't consider it terribly bad.

Yes it looks definitely like a "green" application, meaning its organically grown development is visible in many places. But it's something that is actually workable.

---

Did you go back to the first frame in the stacked structure?  This part is giving me anxiety looking at it:

---

Yes, I saw that, and yes I do not like such stuff at all. However if I would get a fit every time I see such code in applications that I had to fix, or add a new feature, I would have died long ago. 😁

There is much to be improved at this, but as has been mentioned already several times: Going to change things nilly willy will turn an application that seems to work "most" of the time into one that will not work most of the time or even never. It's about pragmatisme. Try to go with what you have and improve things along the way, one wire a time and see where it ends.

But the first step MUST be version control. Even if it is nothing more than an SVN server on a NAS. I do that myself like that and it works quite well. Make the NAS have redundandent disk storage and things are at least fairly safe. Developing any software that is more than a trial and error hobby project, without any version control is nothing more than planned suicide.

[Jay14159265]

---

@LVIEWPQ wrote:

As much as I appreciate everyone agreeing on paying someone else to come in and show you how it should be done, it's not an option. 😕 Hence coming here to ask for advice on starting points with bad code. 

There's no SCC in place either, and the only other person within the business has openly stated it's bodged and bolted on. 

I have attached (one of many) the offending vi, and you'll notice the file name of Block 3 (engine derivative) Cell 2 (test cell) with BK (being the new hardware added in)

Again I may be wrong and it may be perfectly acceptable code, and just looks daunting, but doesn't seem to follow anything I've learned through the courses. 

---

I feel your pain, the courses would never direct you to build something like this. On the bright side, it has comments so its easy to get an idea of what the previous developer was thinking. 

As mentioned before, get the code in SCC. Bitbucket/GIT is a great choice and its free for a 1 person team : ) 

Bitbucket | Git solution for teams using Jira

It also has some great documentation for getting started if you are not familiar with GIT. Some quick pointers. 

1) To make a new repo for existing code that is not in GIT, make an empty repo online, check the repo out on your computer, copy all the code into it then push it back up.

2) Never work on the master branch, even if you are a 1 person dev team, always make a feature / bugfix branch and merge it back into master.

3) if you have never used GIT, use SourceTree to manage your repos locally

Once the code is in GIT, you can improve the code without changing its functionality by starting to break the individual loops and structures down into sub VIs, this process will help you jump into the code and understand it. If the code works now, don't worry about optimizing it or changing the functionality (that can come later), you first need understand it which requires you to dig into it. 

To create a sub VI from existing code, check this out: 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YK4VCAW&l=en-US#:~:text=Create%20a%20....

[LVIEWPQ]

---

@rolfk wrote:

---

@Kyle97330 wrote:

---

@rolfk wrote:

It's a bit unwieldy and definitely grossly violates the "Diagram should be not bigger than your monitor" rule, but other than that I wouldn't consider it terribly bad.

Yes it looks definitely like a "green" application, meaning its organically grown development is visible in many places. But it's something that is actually workable.

---

Did you go back to the first frame in the stacked structure?  This part is giving me anxiety looking at it:

---

Yes, I saw that, and yes I do not like such stuff at all. However if I would get a fit every time I see such code in applications that I had to fix, or add a new feature, I would have died long ago. 😁

There is much to be improved at this, but as has been mentioned already several times: Going to change things nilly willy will turn an application that seems to work "most" of the time into one that will not work most of the time or even never. It's about pragmatisme. Try to go with what you have and improve things along the way, one wire a time and see where it ends.

---

Yeah, so you see that bit? I need to add another DAQ device to this logging, and I just have no idea where to start. 

Can you see why I panicked when this is my first exposure to labVIEW? 

[Kyle97330]

In this particular case I would start just by labelling everything you can find.  Like, find what's on line 5 (i.e. index value of 4), right-click the constant containing "4" and use the Visible menu to show the label, and then change the label to the name of what's on that line. 

Repeat for every other fixed constant, line number or otherwise.  It should make it easier to figure out it what's happening and won't change the way it functions at all.

[JÞB]

With only 6 months of exposure to programming in LabVIEW you have to consider yourself an infant.   TRUST ME I'VE BEEN THERE! and without any mentor to guide the team.  We wound up "potty training " ourselves.  Certainly,  we made mistakes and wound up producing piles of feces!  Eventually, we made enough painful mistakes that our code looked pretty darn good.  It took years and countless man-hours of wasted time.

You need a mentor to show you practical use of the Core Training Material to learn without the pain we endured.