&quot;And it was written on company time, so the company technically owns it.&quot;<p>I figured this and you possibly breaking the rules were the reasons for discretion. I also figured you were forced to use aging crap that motivated you to try alternatives. A painful, but common, thing in industry. Hence, me reminding the other commenter not to expect a source reference on it. ;)<p>&quot;I Work in an aging framework for electronics testers written in a combination of C#&#x2F;VB&#x2F;LabVIEW its highly asychronous nature make debugging the system an issue.&quot;<p>I usually try to drop papers or articles at moments like these but have nothing relevant. There&#x27;s only a few articles in my collection on asynchronous systems (outside I&#x2F;O) because they&#x27;re so hard to verify. I did find a few resources. Would have to know if the problem is communications, data, what before I could attempt suitable references for you.<p>You probably already do one of my base recommendations here: tracing flows and input validation on them. The equivalent of asserts on input and&#x2F;or monitors with read access to global state comparing data&#x2F;states against ranges or rules in a policy. Taint-methods are also helpful where you tag data in the datatype with details about where it&#x27;s been and whats happened. That&#x27;s more advanced and I&#x27;m not sure there&#x27;s libraries available for those platforms. The other technique they can easily handle: I did it in VB long ago.<p>&quot;Screw diamonds: legacy systems are forever.&quot;<p>That&#x27;s friggin&#x27; great. Need to make a meme image out of that with some COBOL or RPG on it. :)