Almost 3 years

As I mentioned back in April, I had several ideas for new posts but didn't have the time to finish them off.  Now it's close to the end of June and I've posted three items in the past week.  I'm catching up.

I am also approaching the 3rd year anniversary of this blog.  That date, along with my recent stops and starts, prompted me to ask, "Where am I going with this blog, and what do I want to accomplish?"

I occasionally use blog tracking software, so I know I get between 200 and 400 visits per month, averaging about 1.5 pages per visit.  That's a minuscule amount by popular blog scales, but test engineering is hardly a hot button topic.  People comment rarely, although I have had a few acquaintances tell me they read my blog and enjoyed it.

I don't get paid for this, it's not a supplement for my job, and I'm not trying to score points with people online.  Why do I do it?  Because a part of me always wanted to write - in college I briefly debated trying to become a novelist.  What do I want to accomplish?  To entertain and educate, in relatively equal proportions.

Okay, that's enough touchy-feely soul-searching for one day.  I hope everyone had a good weekend.

LabVIEW patent digging

I started down this path when I read an article about DASYLab in the April issue of Evaluation Engineering.  That triggered something in my memory about Measurement Computing, the company that published DASYLab.  After doing a little digging, I thought I confirmed what I remembered: National Instruments bought them out many years ago (1998).  But then I found a different article from 2003 stating that SoftWIRE, a subsidiary of MC, had patents it had acquired from Fluke that predate the NI patents for LV.  Hmm.  Finally, I found an article on Bloomberg that states, "as of April 29, 2005, Measurement Computing Corporation operates as a subsidiary of National Instruments Corporation."

But doing all that digging started me thinking about NI's patents.  Dataflow programming was first proposed way back in 1966 by Bert Sutherland, so NI couldn't patent that.  Although, if you do a patent search on, say, NI and programming you'll find hundreds of patents (or look here).  To my knowledge, patents can expire in as soon as twenty years.  LabVIEW was first introduced back in 1986.  Doing more digging, I found yet more nuggets:

• According to this news release, one of NI's key LabVIEW patents expires in April of next year.
• NI spent significant time and money defending a patent against The Mathworks (the MatLAB) people in 2002.
• There was a very interesting conversation on LAVA back in 2004 regarding the SoftWIRE v. NI lawsuit.
• Right around the turn of the century NI was in a LOT of activity: licensing patents and buying companies to resolve patent disputes (ex: here, here, over there, and out thatta way).

So where does this trip down the rabbit hole lead?  Here's what I saw:

1. Many of the original LabVIEW patents are getting long in the tooth and will start to expire as soon as next year, if they haven't already.
2. NI has no problems litigating patent infringement.
3. NI will buy companies to protect patents.

Based on that, here's my prediction: history will repeat itself.  In the next few years there will be at least one software company that develops a software package that competes on the cheap with LabVIEW (which currently runs several thousand dollars per license).  They'll be able to do this because of those expiring patents.  Heck, they may even write their compiler so that it can use subVIs written for LabVIEW.  After this happens, NI will sue them, force them out of business, or buy them.  I imagine they'll buy them out - I doubt they'd want the price point on LabVIEW to drop at all.

It'll be interesting to see how it plays out.

SQL Options

There is a great article on non-SQL databases in the June issue of  Dr. Dobb's Digest.  It basically surveys the NoSQL movement, something that I quite frankly had no idea existed before I read about it this past weekend: non-relational databases designed to handle terrabytes of data across multiple geographically divers systems.  I'm far from a database expert, but I've dealt with them enough so that I could follow the article.

I'm bringing this up today because it dovetails in with a post I wrote almost a year ago.  The point I was making back then was that, with memory and computing so cheap, large amounts of data and statistics would become an increasingly larger part of a test engineer's job.  The Dr. Dobb's article complements this idea by describing the tools being developed to deal with this data.

Test Engineer Bucket List

I've never seen the movie The Bucket List.  Nor have I seen either the MTV show or the CBS special that played on the same idea.  The idea of making a list of things to do has certainly been around for a while.  In fact, a good friend of mine crossed off a major item on his list a few years ago when he bought a Ferrari.  "I could almost die happy now," he said.

When he first took me for a spin in his sweet ride, I started thinking about my own list.  But now I'm putting a different spin on it: a test engineer bucket list.  Before I retire, hopefully a long time from now, what would I like to do as an engineer?

I'm not talking about accomplishments.  It would be quite easy to make a list that included items like, "make a ton of money, receive multiple patents, publish numerous papers."  That's more of a self-serving list than a self-fulfilling list.  Instead, I aimed for things that I would personally want to do as a test engineer, things that I would find professionally satisfying, and things that are just fun. Often we don't think of work as "fun," but sometimes it can be a real hoot.

So I came up with a list of five items.  They're in no particular order, but I think they all fit my above boundary conditions.  Perhaps it will inspire someone to create their own list.


Mentor a young engineer
I don't think I'm quite old enough to seriously consider being the "elder voice of experience" for younger test engineers.  But I can think of several people who tutored me when I was younger.  Those lessons were not really about technical details.  They had to do more with how to deal with difficult coworkers, presenting your case in a meeting, and other things you don't get in college classes.  I'd like to pass on the favor at some point down the line.

Work as a true manufacturing test engineer
Most of my career has been on the R&D side, bringing up a pilot production system, or small production quantities.  I think it would be interesting to see how the other side lives: analyzing massive amounts of data for a thousand devices tested a week, troubleshooting an entire floor of test systems.  Maybe I'd do it for a few months, maybe a few years.

Be a consultant
This is similar to the "manufacturing test engineer" item above.  I worked in sales for a couple years, and that scratched a particular itch.  Trying out my hand as an engineering consultant would be another one of those itches.  I've worked with several consultants, and sometimes I've thought it would be fun to try that career change out for a while.

Develop a test system that measures a fundamental aspect of the universe
I used to do this, a long time ago.  Over the past decade I've worked at startup companies trying to commercialize bleeding edge technology, and that has it's moments.  But nothing beats the thrill of measuring something that stretches the bounds of science itself.  It'd be great to experience that once more.

Write a story about a test engineer
This would definitely be on the "fun" list.  I don't think I've ever read a novel about an intrepid test engineer braving impossible odds to save the day.  I do think it would be a blast to try and write one.