From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

IS UPDATING THIS CODE WORTH THE EFFORT OR SHOULD I START FROM SCRATCH?

Fix it in its current state and note how long it takes.

 

Then re-write it from scratch and see how long that takes.

 

You then know which one you should have done.  Smiley Very Happy

 

But on a more serious note, it's hard to give reliable advice on these things because it often depends on so many external factors (Your ability to refactor code, whether your boss sees refactoring as a waste of time, how many future changes will be made to the code and so on).

 

If you're asking the question of whether you should refactor it or not, it's usually time to do so.  But being practical requires that the refactoring process be intertwined with existing deadlines and so on.  Knowing WHEN to refactor is almost more valuable information (and harder to decide) than WHETHER you need to refactor.

 

Either way, good luck.  It's always possible to choose a halfway point (Refactor some aspects - low hanging fruit - and leavde the major cleanup for a time with more resources available if time's tight).

 

Spoiler
I've come across different types of programmers.  Some are delighted at the small details and love tweaking here and there and are kind of happy to wallow in an understood complexity.  Others prefer to have a self-explanatory architecture which only shows the implementation details when really needed.  Which kind of code is best suited depends a lot on who's going to be continuing the programming and what the culture of programming is in your place.

 

Message 11 of 12
(305 Views)

Remember, that in either case, rewrite or patch existing, you will have to "requalify" the test program to someone's (Quality group?) expectations. This is proving that the program performs as expected. Of course, this requires someone having hopefully documented what "expected" means. What does the program do, what measurements does it do, to what accuracy, what does it control, to what accuracy. Also consider safety, you have mentioned controlling high power equipment, what safety measures does the program currently have/need. In programs like this it makes me very nervous, with race conditions, etc., that "features" have been added willy-nilly, stuck on with software Duct Tape. As everything is sort of "hanging out in the breeze" there is no error handling, so if one part fails, there is no way to know it or have it gracefully control the rest.

 

 

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



Message 12 of 12
(273 Views)