Spam

Well, today I had to implement word verification for comments to my blog. Up until a couple months ago I'd never had this problem. Test engineering is not exactly a hot button topic, so this blog never gets more than a couple dozen hits a day. I probably flew below the radar.

But starting early this fall, and accelerating the past couple weeks, have been a lot of badly-phrased comments advertising drugs and websites of the usual varieties you see in spam. I guess the auto-generating junk-mail code out there is starting to expand.

So now I've implemented captchas for anyone who wants to add comments. Hopefully that will cut down on the comments I have to delete.

Test engineering fears

I originally planned to write this post for Halloween, but my schedule slipped. Today is Friday the 13th, so that's a decent fallback position.

========================

My middle child was talking about scary movies and what he thought made them scary right before Halloween. That started my thought train on what I fear as a test engineer. More specifically, what a test engineer at a startup fears. Here's my top five:

5) Bugs caught by management

In a small firm most everyone helps out, even management . When you write code, bugs are inevitable. It's okay when other engineers spot the bugs, but it's really embarrassing when the CEO emails you about a mistake he found in your program.

4) Feature creep

Things are always changing in a startup, and that most definitely applies to the testing process. You come up with better ways to test the DUT, you come up with new things to test on the DUT, you speed up your testing, etc. All of these things are fine, but sometimes they feed into extraneous changes to the test system. A design engineer may think, "Hey, it'd be really cool if I could see this set of data while the test is running," but any change like that takes time, and those changes can eat into the time you need for something else.

3) Bad requirements

Worse than feature creep are bad requirements. Suppose you are told that you need to measure current and temperature of a DUT under specific load conditions. So you get the hardware, set up the software, build the station. THEN you are told that - oops - we also need to measure optical parameters of the DUT under a separate set of conditions as well. Suddenly, you have a serious rework on your hands. That scenario can happen in a startup, and it's a real pain.

2) Data getting lost or corrupted

In every startup I've been a part of, data management is a problem. In the beginning, it's easy to sort your data and analysis work with a combination of spreadsheet files, text files, and a good subfolder setup on your network. As the startup grows, you have to implement a database, which introduces its own growing pains. In the meantime, your company lives and dies on that test data. About 4 years ago I had a problem at a startup where an entire set of test-data subdirectories was accidentally deleted from the network by an engineer working in his own directory. I spent an entire day getting the IT guy to get the network backup from two days before and then figuring out which devices had to be retested. Gruesome.

1) Great test results

This is my top fear. At a tech startup you are developing new technology. Things aren't supposed to work right. You have problems with the manufacturing process, you miss key design issues, or you discover unexpected behavior. When I see great test results from a DUT I get nervous; my first thought is that something is screwed up with the test equipment. So I will do a quick check of the hardware connections, software design, and the algorithms used. Good results can play havoc with my sense of well-being.

Post Eleventy One

I didn't realize until last month that I had recorded 100 posts to this blog. By then it was too late to really say anything about it, but I wasn't about to pass up a chance to commemorate 111.

Why that number? You could say that it's because of the interesting information about it on Wikipedia, the fact that it is symmetrically slick, or even that it was Bilbo's birthday when he left the Shire.

But really, it's because in binary form the number 111 converts to 7. And as everyone who watched Saturday morning cartoons in the 70s can attest, seven is a lucky number.

LabVIEW source code control, Tortoise, and JKI

All programmers should know the advantages of source code control (SCC), so I'm not going to talk about that. What I do want to touch on is using SCC with LabVIEW.

I've used Tortoise SVN for close to three years now with LabVIEW. It works pretty well, although LV doesn't sync well with SVN. Several years ago I used Visual Source Safe, and I liked being able to check files in and out from within the LV development environment. So I was happy when I saw JKI say that they had a Tortoise tool. I installed it later that summer, but then LV2009 came out so I had to re-install it.

I don't use it anymore, for one simple reason. Everytime I try to check something in or out, this annoying popup appears:

I might as well just go to the explorer window to check in & out, which is what I've done for years now.

I can understand JKI wanting to make money for their work (although $99 seems steep). But that pop-up appears every single time... it has annoyed me so much that I'll never buy it. Too bad, because otherwise JKI seems to do great work.

Catching up

As you may have noticed, I've posted more to this blog the past week. I was swamped this fall. After a fairly productive July and August, I posted a single post from September to October. I had ideas for posts, I wrote down snippets, and I tried to schedule time to finalize thoughts. But that last step can be a stretch. Regardless, I'm catching up now and expect to have at least 4 more in December. I hope you get something out of them.

Climbing mountains vs building roads

I read an obituary for Israel Gelfand a couple weeks ago, and it struck me as a very interesting read. I especially liked the travel analogy comparing the mentalities of two great Russian mathematicians:

“Suppose they both arrived in a country with a lot of mountains,” Dr. Retakh said of Dr. Arnold’s comparison. “Kolmogorov would immediately try to climb the highest mountain. Gelfand would immediately start to build roads.”

As a test engineer more often than not I'm building the roads that others will use to get to the mountains. And I like that.