It Isn’t Always You (It Usually Is… But It Isn’t Always)

I’ve spent a lot of hours and years grinding out code. This means I’ve had to solve a lot of problems, many of my own making. Seriously, almost every coding problem is the local programmer’s fault and can be fixed by that programmer. If that person can’t fix it, find someone who can, even if they’re only going to Google StackOverflow. Or, as Jeff Duntemann would say,

“There is in old saying to the effect that, after you spend hours banging
your head against a bug, someone completely foreign to the situation will
walk into your office and immediately spot the flaw. It’s true, and
something you should use often. If necessary, lure them in with food.”

That said, if elbow grease and contemplation and help and Google and dishes full of sweets don’t get you anywhere, you might just have a problem with the tool. I’ve run into four that I know of.

1. The first data archiving system I wrote, for a mill in Kansas City, made use of variant records, also called free unions. The system stored the heating history of every billet processed by the furnace, and these files were appended every 50 seconds. All of the records had a fixed part and a variant part. The variant part was needed because the archive files were based on a fixed record size and the header information (the first entries in the file that described the billet’s ID, dimensions, chemistry, and so on) were much larger than the information that needed to be stored during heating. If all records were going to be of the larger size then the files would be filled with a lot of empty space, which kind of hurts my soul. Oh yeah, and there wasn’t that kind of disk space to spare. The solution was to break the header up into two or three separate records so each would be the same size as the heating records. I wrote the code to write the records into the files and everything worked famously.

Until I went to read the files and display the results.

When I read the records back out the information in the variant part of each record was garbled. Looking at it bytewise I saw that the data had been shifted two bytes in the variant part of the records. I struggled with this for two solid days. The target system was written in FORTRAN for a DEC VAX machine running VMS. I was developing the code in parallel in Microsoft FORTRAN PowerStation 32 (on the PC, I think in Windows NT) so I could debug more efficiently and work at the hotel in the evenings. After a few calls to Microsoft they recorded the problem as a bug (the compiler was aligning one of the items on a four-byte boundary when it should have aligned it on a two-byte boundary) and told me that it worked just fine if I changed the order of declarations in the variant part, so the first data member was of a different type that the compiler would align correctly. I did so, and the fix worked.

I tried it both ways on the VAX, and both worked. Its compiler did not insert the extra two bytes and I might not have needed to spend so much time on it.

2. I was in a good flow banging out model code in Borland C++ Builder for a mill in Memphis when my ongoing testing showed that one of the statements I wrote wasn’t executing. I went back several times to step through the code in the debugger and when stepping through one line I saw that the calculated value did not change; the code was having no effect. I looked at it over and over and kept coming up with nothing. I finally decided to insert a dummy statement just ahead of the offending line. I set the value of a global variable so the compiler wouldn’t optimize away a similar operation on a local one. Boom. It worked. The calculation was now carried out and that result was generated as expected.

That one hurt my soul a little bit, too, but I could live with it.

3. The next one also came up on that project in Memphis, but it was different. One of the other vendors wanted me to send him files via FTP, so I used the FTP component provided by C++ Builder. It worked just fine, but every morning I’d come in to find that my system was locked up. I eventually figured out that there was a memory leak in the FTP component, about which I could do nothing. The other vendor accepted my proposal to read and write files on a mapped drive instead, which solved the problem.

4. The last one I found was in SLX when I first got to my job at Regal Decision Systems, in Baltimore. I was writing a tool to simulate the operations in medical offices when one of my runs crashed in spectacular fashion. I was able to identify the offending line in the debugger but everything looked in order to me. I contacted the gentleman who maintains the SLX code base and sent him the code and data I was running. He was able to reproduce the error, which was lucky enough — or is that unlucky enough? — to break a piece of SLX’s code in a way that hadn’t been done before. He said that particular piece of code must have run billions of times without breaking but did not offer specifics about what went wrong.

The bottom line is that if you code long enough you will almost inevitably encounter issues with the tools you’re using. Remember that the people who create the tools are just like you, though possibly with more education and experience and with better management. Sometimes you can find a workaround on your own and sometimes you can’t. In the latter cases I hope you’ll be able to get the help you need.