Seeking advice on how to deal with inherited code

[LVIEWPQ]

So I'm relatively new to LabVIEW, (~6 months in) and I've been tasked with taking over maintenance of our test rig control programs (engine testing cells - control and measurement run through labVIEW) 

I've done Core 1 & 2 training courses, and the way you are taught to build code on the course... our stuff looks nothing like it. It's all over the place and enormous expanses of code. Each engine has its own program written for each different test cell, and working out what each bit of code is doing is tedious as labeling wasn't really their thing.  

My full time job isn't to maintain code, I've actually got to run these test cells and deal with the code in between tests. 

So, my question is, what would you suggest is the best way to deal with this monstrosity code? 

Full rewrite (which I'm not exactly confident doing) or is there an easy way to identify certain parts of their code so I can label them and modify one to be a bit more universal

[JÞB]

---

@LVIEWPQ wrote:

So I'm relatively new to LabVIEW, (~6 months in) and I've been tasked with taking over maintenance of our test rig control programs (engine testing cells - control and measurement run through labVIEW) 

I've done Core 1 & 2 training courses, and the way you are taught to build code on the course... our stuff looks nothing like it. It's all over the place and enormous expanses of code. Each engine has its own program written for each different test cell, and working out what each bit of code is doing is tedious as labeling wasn't really their thing.  

My full time job isn't to maintain code, I've actually got to run these test cells and deal with the code in between tests. 

So, my question is, what would you suggest is the best way to deal with this monstrosity code? 

Full rewrite (which I'm not exactly confident doing) or is there an easy way to identify certain parts of their code so I can label them and modify one to be a bit more universal

---

Find a Certified LabVIEW Consultant to work WITH you to first reverse engineer and evaluate the current state of the code (including staking it in a SCC repository!)  Then work WITH this advanced developer and your manager to find the best path forward for your group's needs.  Write the documentation of how the resulting code will be architected and tested.  Write and test the code to plan.

See! it sounds simple when you think about the solution rather than the problem.

[rolfk]

I have in my 30 years of LabVIEW programming "inherited" many programs and each and every has been different. From the single VI monster application with stacked sequences of loops inside stacked sequences of more loops and cases inside yet more loops and sequences to spaghetti code and the other extreme of random subVIs all over the place without any useful modularization and cross contamination between those subVIs.

So an easy how to recipe is not something I could come up with. I would echo JpB's recommendation. Try to find an experienced partner that can work with you to refactor and maybe redesign those applications from the ground up. It will be initially more expensive but it will be a much more sustainable path to move forward from in the long run.

[jcarmody]

Something to consider: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ 

The previous posters have tons more experience than me, but I still think rewriting a working app needs a very strong justification.  You might do well just to engage a consultant to help you understand & document what you have so you/they can maintain it going forward.

[santo_13]

It is definitely painful to understand and change an existing code. If your company is not ready to spend on a consultant, they must understand that it is unrealistic to expect a beginner as you to do anything in short span.

[JÞB]

---

@rolfk wrote:

So an easy how to recipe is not something I could come up with. I would echo JpB's recommendation. Try to find an experienced partner that can work with you to refactor and maybe redesign those applications from the ground up. It will be initially more expensive but it will be a much more sustainable path to move forward from in the long run.

---

At great risk I will beg to differ with rolfk.  While hiring a highly experienced developer is not cheap, you have to factor in the cost of the hourly wage of the inexperienced developer who has never reverse engineered and documented existing code before.  Then multiply that by the overtime or job dissatisfaction he will endure to add that task to his regular duties which will be neglected.  Finally, factor in the forward looking cost savings the knowledge and mentorship will bring to future projects as well as the reduced maintenance costs directly associated with the project exemplar.  The PRICE per hour may sound high but, the project COST will be significantly reduced by engaging a Partner/Mentor.  I'll be brutally honest, I charge more per hour than you get paid.  My experience is that it requires far fewer hours for me to do the work than a unseasoned developer.

[Bob_Schor]

Hmm.  When I read what @rolfk says, and then read @JÞB's response, I think that he and @rolfk are really saying the same thing.  If you put an Expert and a "Trainee" together on a Project, with E$ being the monthly "cost" of the Expert and T$ the monthly "cost" of the Trainee, and it takes M Months to complete, the "obvious" cost will be (E$+T$)*M.  You are bound to get a far-superior product (as it will reflect the "expertise" of the Expert), and by the time the Project is finished, the Trainee should be half-way to being an Expert, her/himself.  Granted, it may take a little more time with E+T (as the Expert will spend some fraction of his/her time training the Trainee), but the difference in time with two Developers (even of unequal skill -- talking to an inexperienced LabVIEW user, I find, is a much faster way for me to find my own bugs than talking to my Rubber Duckie, although that also works).

The additional benefit will be Much Better Code!  All VIs will be documented, everything will be under some form of Version Control, and there may even be Writeups and Manuals produced.

Hidden cost (but also hidden benefit) -- following this experience, the (former) Trainee should be able to command a higher salary, but will definitely be prepared to earn it!

Bob Schor

[rolfk]

Bob already explained it. The initial cost of hiring a real professional to review and rework the application together with the client is for sure higher than if the not so experienced customer starts to hack along in the messy code to add this little feature here, and fix that obnoxious bug over there.

The result is however a very different one. In the first case you should end up with a much more maintainable code base and for sure learned a bit or two along the way of how a good application should be build in the first place. In the second case it is likely that the not so experienced customer managed to fix a bug or two by tacking even more code to the very brittle building and in the process likely adding several more latent bugs.

[LVIEWPQ]

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. 

[rolfk]

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.