01-14-2014 06:27 AM - edited 01-14-2014 06:31 AM
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.
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).
01-14-2014 09:11 AM - edited 01-14-2014 09:13 AM
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.