Atlas LHC - Very cool stuff

As I've mentioned before, I cut my testing teeth in high energy physics.  Once again, I'm cleaning out my in box and I found a great article in Evaluation Engineering about the Atlas Experiment for the Large Hadron Collider.  It's chock-full of details about all the different measurements they do, and it sort of made me nostalgic for my grad school days - sort of.  

At any rate, I'm pretty sure the massive detail the test engineers at Atlas have to deal with exceeds the difficulties Intel has when testing it's chips. 

BTW, here's a funny cartoon that came out about the time the LHC went online.  Perversely amusing:  http://xkcd.com/401/

Sifting through my inbox - CAST

So once again I'm going through my Inbox and sorting through months of miscellaneous emails.  I came across this  press release about the Collaborative Alliance for Semiconductor Test (CAST).  here's the key quote:

CAST was formed in 2008 by semiconductor device makers and test industry suppliers to engage in, and resolve, common industry issues related to higher test equipment utilization, lower costs, and greater standardization and return on test-related R&D. 

Sounded interesting, so I went to the website for the group.  They had a little more information there, including slides from a meeting a couple weeks ago.  The list of member companies includes mostly test equipment companies (no surprise there) and big users of semiconductor test equipment (i.e. - Intel).  

I'm all in favor of things like standardization and lower costs, but these sorts of organizations tend to founder unless they are led (at least in the early days) by a strong leader.  I wish them luck.

----------------------

After a month+ of not posting, I finally have a little more time to get back to the blog.  I have at least three more items I'll be posting over the next week or so. 

Test Engineer - the musical

I haven't posted in a while - mostly due to tax season, a long project a son needed help with, and of course work keeps me busy.  But here's a funny series of songs about testing.  They were recorded by Martin Rowe,  the senior technical editor at the Test & Measurement World magazine.  Although acoustic blues aren't really to my musical taste, I really appreciated the sentiment.

Engineers in sales

Almost two years ago I wrote about moving from testing into sales.   In the February issue of Evaluation Engineering is a pretty good essay about this topic.  In the article Malcolm Levy (the author) covers why an engineer might move into sales, what skills are needed in a sales role, and how to get started moving into that position. 

-----------------

I've been clearing up some accumulated junk in my inbox again (magazines, app notes, newsletters), so I'll be posting at least a few more times this month.  

Optimistic skepticism

I've been deep into updating two separate test stations recently, and I almost repeated a mistake I made last fall: wanting the code to work so much that I willingly believed that a bug had just one source.  Fortunately I dug deeper and found three separate sources of a single bad result.

For a couple of years in the late 90s I tested software for HP/Agilent.  When you test software, the goal is to break it.   You go to your job thinking, "What would a user of this software do that the programmer would not expect to happen, and will that behavior break the program?"  It was a difficult gear change at first, but I think it made me a better programmer (that's the reason that many young  programmers at Microsoft get their start testing code).

A primary goal of a programmer is to get his code to work.  There's an indescribable, almost physical thrill you get when an algorithm you've invested so much time into comes together and performs.  To subsequently try to break it is a literal buzzkill.  

Test engineers, at least the ones who also write code for their systems, are sometimes stuck between opposing priorities.  On the one hand, you enjoy building a new system that works.  On the other, the system has to work all the time - the worst result from a test system is erroneous data that you think is correct - so you have to spend a good deal of time trying to break it.  

It's a tough row to hoe, but that's just part of the job.

Adhering too tightly to the requirements

I've been really busy at work the past month plus - but I'm employed, so my complaints are few.

Read this article and watch the video (also on youtube).  The part that really troubled me was when the engineer says "this is just bad engineering" and the manager says:

That might be, but I can’t afford to worry about that. My job is to make sure the project follows this plan from start to finish.

There are two sad parts to this.  First, that this was a real event that happened at NASA.  Second, that I've seen some of this same behavior at big companies I've worked at before.  The management adheres to the process, and all the documentation they have, even in the face of contradicting data.  

As a test engineer, that is especially abhorrent to me: valid data is what I work to create for a living.  For a manager to favor process over data is just wrong.

Still around after the storm

It's been a busy month, personally and professionally.  Aside from new hires and a reorg at work, on December 11th there was a huge ice storm in the New England area that knocked out my electricity for ten days.   Luckily I got it back before Christmas - some people weren't as lucky.

Anyway, I have several more posts that I'll be getting up this winter.  As I've said before, I usually flag emails/articles/etc. when I find something interesting to say.  I'm about due for another clearing of the in-basket.

 

Shot of the woods near my house the day after the storm.