The Republican Brain

Science and technology are very important to me.  I look back on the thousands of years of human civilization, of failed empires, of the rise and fall of governments and it just makes me sad.  Then I look at how far civilization has come in just the past few hundred years, and I'm hopeful.  Maybe it's a little bit religious, but I do have faith that most people are basically good and, if we continue to emphasize scientific and engineering advancements, humanity will prosper.

Then I spend a little time watching Fox News, or reading a website like this, and I get depressed again.  The earth is getting warmer.  Mankind evolved from apes, which evolved from earlier species, all the way back to primordial ooze.  The Earth is a few billion years old, not 6000.  All these statements are supported by mountains of evidence and theories.  Why don't people accept this?  I finally got around to reading "The Republican Brain," and I have to say it was very convincing.

Labview versioning hell, pt 2

Back in July I wanted to look at some fairly old code I had stumbled across - in the past I've had to do this a time or three.  This code was too old to up-convert with the version of LV I had, and I didn't have access to any older versions of LV.  While I worked on posting the code online to ask someone to convert it for me, I posted a suggestion to the LabVIEW Idea Exchange.

Basically, I was asking for a way to at least view very old code, and maybe include reasons for why it couldn't be up-converted.  The response I got was, basically, "If you are an SSP member you can download older LV versions.  If you don't pay to keep up your SSP, you're SOL."

Needless to say, I found that less than satisfying.  First of all, why would I want to spend the time and effort to download and keep track of older versions of Labview?  Second, it sounds like just another way to have owners of the LV software to continually pay money to NI...

Test your code

So at my new company I'm back to software testing.  What goes around comes around I suppose - I first learned the ins and outs of software testing at HP about 15 years ago.  Even though most of my jobs have been hardware testing since then, I still enjoy reading about it (i.e. - here, there, and way back then).  As my dad has said many times, it never hurts to learn something new.

Speaking of which, I recently found two articles about the costs of NOT testing your software that I enjoyed, in a perverse sort of way.  The first article is a bit esoteric unless you've done serious code testing before.  Basically, it explains how Kaspersky released an update to software that wasn't regression-tested.  In other words they made changes to the software, and, while they may have tested their changes, they didn't test whether those changes would mess up the base code.  That's the whole point of a regression test suite.

The second article is of somewhat more personal importance.  For a long time I owned only Toyota cars.  But once I started reading about braking problems back in 2009, I decided to buy Ford instead (here and here).  This past October a court finally ruled against Toyota, and central to the case was the Engine Control Module's firmware.

Will companies forever keep neglecting software testing in favor of releasing product ASAP?  I mean, just reading a paper like this from NASA and anyone with half a brain should realize that software testing is of paramount importance.  Jeez.

More salary surveys

I have a thing for salary surveys (here, there, and back then).  I will admit to using them as a gauge of how fairly I'm paid.  But I also think they're interesting because...

• A good salary survey will break it out into several interesting data trends.  And I'm a geek for data analysis.
• I like to see how engineers feel about their own circumstances
• It's interesting to see how it relates to where the economy is

So, here's a couple of surveys that came out in the past month or so.  Enjoy.

Design News 2013 Salary Survey

Dr. Dobbs Developer Survey

Getting back to the blog

I'm getting a handle on things at my new job, so I'm looking to start posting on here at least a few times a month.  When I've come back from a break in the past, I usually create a list of what I want to post on.  This time around I'll just wing it.

Yet another startup

I'm sure there's a 12-step program for this somewhere, but I think I may be addicted to start-up companies.  Last month I joined my seventh (or maybe eighth) high-tech startup firm.  As I've written numerous other times (here, there, and back then, to name a few), I have landed at numerous early-stage companies over the past dozen years or so.  That's one upside of living in the Boston area - there is never a shortage of smart engineers wanting to start a new high tech company.  And they all need test engineers.

At any rate, I may have to put this blog on hiatus for a while, again.  The startup experience can be intense at times.

But now that I think about it, start-up companies could be fodder for a couple more posts....

Test Executives - part 3

I started writing about test executive software last month, and then a couple weeks ago I wrote about off the shelf software.  Now I want to write about my experiences with "rolling your own" test executive.

I've worked with homegrown test executives at two different companies.  At the first company the test executive evolved out of a couple of different programs for testing different features of the same product.  In the second company, I worked with a test executive that had been written several years before I started. I'll address each one in a separate paragraph.

The executive I wrote myself was somewhat rudimentary.  For the products we were manufacturing, there were six distinct tests you could perform.  Each of those tests had from about 3 to 20 different numerical parameters that could be adjusted.  This just screamed out for scripting, so that's what I did.  The end result had the configurability I needed, and it was often used by test technicians, but it was missing several other features of an off the shelf system test executive:

• It was only usable within the Labview framework I had written.  For example, it couldn't interface with any modules written in C++  without a lot of extra coding.
• There was no programmatic logic in the scripting.  The scripts consisted entirely of what tests to perform under what conditions - no if-then or optional looping allowed.
• Some reporting tools existed, but mostly in simple formats (saving CSV files or bitmaps of graphs).
• It was written with testing a specific product, and had to be overhauled to test some other type of product.

The other test executive was written in .NET and made use of Measurement Studio for certain graphical presentations.  The scripting tools had quite a bit of programmatic control, and the reporting tools were more extensive.  But there were different problems.

• Because it had been designed as a reconfigurable tool, it was horribly complicated to use.  We didn't let technicians near it without a lot of training.
• It was only usable within the .NET framework and didn't play well with other modules.
• It was written with testing a specific product, and had to be overhauled to test some other type of product.

That's a brief synopsis of the two in-house test executives.  So, what is the point I'm trying to make?  I'm not really saying that you should run out and buy a copy of Test Stand.  It's certainly a nice piece of software, but it's expensive and may be overkill for what you need.  I guess the lesson I've learned is that if you get to the point were you want to develop something for yourself to reuse over and over, learn from how the OTS software does it.  Specifically:

1. Don't make it overly complicated
2. Make it generic enough to use for different tasks
3. Use programmable logic in the scripting
4. Have plenty of reporting tools