CodeSOD: Sensing a Problem
Talking to external hardware is often hard. Especially niche hardware devices, which frequently have terrible documentation, bad APIs, and many undocumented quirks that can only be learned by working with them.
For example, Sandra, still with InitAg frequently has to work with hardware. As Sandra puts it: "Most people tend to imagine agriculture as Farmer Bob and his tractor, these day's it's as much drones and high-precision GPS as it is tractors and manure." Which, the technological focus in agriculture is one of the key drivers of right to repair laws, but that's a whole different class of WTF.
What needs to be repaired in today's story is one of Sandra's peers. They were writing code to interface with a hardware sensor on an agricultural device. Sandra omits the specifics, but the key details are that the device might be configured to have a left and right sensor, or it might have just one- either through configuration, debugging, or failure. Also, the vendor API wouldn't return the sensors in any particular order. The software needs to handle those scenarios, and then simply report a signal on the UI reflecting the sensor status.
Now, one place to manage this would be to create some compartmentalized code, buried deep at a low level of the system, which handles and abstracts out all the hardware interfaces. Since it involves I/O, you'll also need to make sure that it doesn't block anywhere in the main loop while you're doing that. Wiring it up to the core software properly will likely involve some sort of message-oriented or event-based approach, probably wired into the message bus your complicated, multi-sensor hardware platform is already using, and is a super-standard approach for industrial hardware and robotics systems.
The other place to manage it would be to just dump the code right in the middle of the main processing loop of your incredibly complex system, with fully synchronous I/O.
# check if the camera are working and send the result to the UIsensors = data_streamer.sensor_data_streamer.sensorsleft_sensor_works = Falseright_sensor_works = Falsefor sensor in sensors: if sensor.is_right_sensor(): right_sensor_works = sensor.check_sensor_connection() else: left_sensor_works = sensor.check_sensor_connection()
The key problem here is that this code blocks three times, and creates some procedure-level variables for the application's main loop. And remember: this code is controlling a piece of large scale agricultural equipment that has very strict timing constraints for how all of its modules link together and talk to each other.
The good news was that this got caught in code review, but it was still surprisingly difficult to take out, as the responsible developer, several other devs, and some of management didn't see the problem. After much explaining, they finally were made to understand that "stopping the machine from doing anything else for large fractions of a second while we talk to hardware is bad. Also, random essentially global variables that drive UI features in the middle of the main loop- not a great look.
This code didn't ship- but the company has shipped code that doesn't look that dissimilar in the past. Learning can happen.
[Advertisement] Keep the plebs out of prod. Restrict NuGet feed privileges with ProGet. Learn more.