Yup to both. First, establish source control. And then stay alert to billko's caveat about race conditions. Bad code sometimes depends on them.
My most recent time bitten: updating a test system with bad sprawl-like code running on an old latop with a low-cost USB DAQ device. We updated to a new desktop PC with a better PCIe DAQ board. And we immediately started getting fatal buffer overflow errors.
Huh? A faster PC and faster DAQ device & bus connection is having a *harder* time keeping up with buffered DAQ? How does that make sense?
Well, it doesn't. But it was the wrong question. Once I dug up the source code for the application, I found a very special kind of race condition. The first DAQ buffer read was setup to happen at just about the moment the buffer was due to be full. However, because the old USB device was a bit slow at getting configured and started, the code arrived at the buffer read just barely before it overflowed. The new desktop board was enough faster at getting configured and started that the code now arrived at the buffer read just barely *after* it overflowed.
This is different from the typical race conditions we talk about here (usually caused by writing to shared local/global data from multiple places -- and the code in question had plenty of those as well), but it illustrates how bad code can contain surprising dependencies and side effects. Navigating it can feel like having to walk barefoot through a cow pasture at night.
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
