Disconnected Catch-Up

A few weeks ago I found a circuit board error at work. We were trying to add a new feature the product, and nothing involved in the new feature seemed to work. It was just about driving me batty. Finally I figured out one problem was do to a processor setting that had greater impact then I suspected. But the relay just wouldn’t work. We even went back to the original software and it didn’t work. We checked signal levels and nothing was changing. But this was a release product, so it had to work, right? Well, no, actually it had been a revision of a previous design, and for whatever reason, that relay was not part of the quality inspection; it had never even been tested when the new board was being approved. So now they’ve got a bunch of board to fix, and the customer has to decide if they want to do field recalls. At least we caught it, and before production continued any farther.

There were certainly some grumbles about all the fuss and work this caused. Which got me thinking about mistakes and reward structures, and how that may impact quality (there it is again) If I wasn’t conscious of it, I might have learned that finding mistakes is bad – it makes everybody upset, and causes a lot of expense and trouble. But something I’m very familiar with from software literature is that the cost of fixing a problem increases dramatically with time. So it seems like the best thing to do would be reward finding mistakes. Of course you have to be careful; if people can profit from their own mistakes, they might introduce them intentionally. Really you want not mistakes to begin with, but if reward that, then there is incentive to hide mistakes. It’s kind of a thorny problem.


Meanwhile, some slightly disruptive server upgrades have been happening at work, leading to some weekend time. Messing, on one hand with the company database, and on the other with the ability of people to log into the company network, isn’t something that should really be done during business hours.

The database was a fairly old FoxPro system – moving was mainly a matter of copying the files and pointing everybody at the new location. Upgrading from NT to Windows 2003 has been more interesting. Active directory is a shining example of the spiraling layers of complexity engendered by mature software systems.


Audio books have mainly been collections of Issac Asmov short stories. One of them, The Complete Robot, felt around the fuzzy edges of the three laws of robotics, which appeared in nearly every story. The last story, The Bicentennial Man, I saw a few years ago in movie format. The movie was certainly an adaptation, adding several elements, such as a love interest, and removing others, such as calling attention to the breaking of one of the laws in the climax.


Not too much else going on; several meetings of the board game designers group, but I haven’t had much time to make a lot progress on my own designs. We’ve also been looking for more members to improve average turnout.

One Comment

  1. flower76 says:

    He lives! :)

    I was just wondering about you… it’d been a while since we’d heard from you. :)

    As a software tester by trade, I hear ya about the conflict between finding bugs early/saving money and being considered a huge pain when you do find a problem. Luckily, while my manager is a huge *#$%% in some ways, he usually does an excellent job of shielding us from the fall-out. It helps that our actual programming is done by an external company and that we, as testers, are employed by the people who actually design and sell the software (removing the fear of finding bugs just to charge money to fix them). But, strangely, even thought we’re the ones who verify that the product shipped is as close as possible to the product imagined, we are one of the least paid departments in the company.