This outsourcing example was truly a nightmare and this type of nightmare is NOT at all uncommon with outsourced engineering. This problem involved the API interface to a standalone bar code scanner.

The outsourced software company created an SDK to read the scanned data from the bar code scanner. Normally you connect to the scanner, send a command, and receive the data. The SDK should handle the communications and most of the retries and error recovery. The SDK is normally designed to make programming the interface faster and easier. This SDK was complex, error prone, and the interface programming was extremely complicated.

The application program had to read each data block from the scanner and respond to each block. It had to check status codes to determine if the data was read properly. If the data was not received properly then the application had to manually do retries to read the data from the scanner. I contacted the engineers and told them that this complex interface was not acceptable. They told me that sometimes the data receive function in the API times out and the application must resend a data request and retry the read.

These “senior” outsourced engineers made a very rookie mistake in their engineering. In Windows when reading a block of data you normally specify a buffer and a timeout period. Let’s say that you specify a timeout of 100ms. The read function issues a read command and waits. If no data arrives then it loops and reads again. This looping continues until data arrives or until the application is stopped. A problem arises when the read is initiated, 98ms goes by, and 10ms of data is sent. The read times out after 2ms and the remainder of the data is not read. If the read window remaining is less than the time it takes to transmit the data then you will not read the transmitted data.

This situation resulted in the application retries, a very complex application interface, dozens of extra pages of documentation, and lots more program code in both the SDK and the application. A software geezer would not make this type of boneheaded programming mistake.

The proper way to program this interface is NOT to issue a serial block read command because of the timeout threshold of the read block command. When building this type of interface you loop on a single character read. If you get a timeout then you try again. If you get a single character (the first character in a longer data stream) then you initiate a block read and place that first character as the first character in the block. When the block read is issued you have the entire timeout length to read the scanner. You will NEVER timeout when reading data. If the SDK was written properly it would have DRAMATICALLY reduced the code required for both the SDK and the application, the interface would have been trivial to program (rather than a nightmare), and the documentation would have been MUCH simpler.

This was probably one of the worst outsource cases. The interface was so difficult that the product did not sell and it was discontinued shortly after this. The company probably lost hundreds of thousands of dollars of revenue because the outsourced engineers did not know how to properly program a serial SDK interface.