Several weeks ago I helped a friend of mine by creating a library for working with HackRF One gadget from LabView. They were having some issues that I couldn’t debug remotely for the lack of that piece of hardware. So I went to their office, connected the peripheral to my laptop, reproduced the issue on a Linux host and figured out a workaround for it that could be implemented entirely in LabView (without needing to change the wrapper library). The problem was that the flow broke when the device was stopped and started again. The idea was to clear the data buffer before starting the device. Vazgen implemented it in LabView quickly, but the hack looked too ugly and I was determined to fix the library. Yet the hack didn’t work! It turned out that the proposed procedure for clearing the data buffer took it into an invalid state and made it unusable. A second level hack (intended to fix the original hack) was born - after emptying the data buffer, let’s destroy and recreate it, thus clearing the bad state flag that was turned on by the underflow. Now everything worked nicely! And then Vazgen noted that we don’t need to empty the buffer if the next thing that we are going to do with it is destroying it. Fair enough! The second level and simpler hack superceded the original and uglier hack! The solution was so simple that we agreed that the library, although asking for improvements, can be used for the time being without any changes.