Happy New Year

Happy Holidays, and I hope 2010 treats you better than the last. Heck, I hope the next DECADE treats you better than the last.

JMP 8.0

I upgraded to JMP 8.0 this fall, and it's great.

I'm in danger of being redundant, since I've mentioned this software package FOUR separate times over the past couple years: here and here in 2007, briefly in 2008, and again this past summer. But I've used the software regularly since 2005 for data analysis and presentation material. I really like it.

Anyway, I wanted to give props to SAS for the latest version of JMP. There are a few big things they added (I liked the animated graphs) and several smaller additions, but the best feature for me has been the graph builder. In the past when I was trying to see a trend in data I would graph some things as linear plots, try them as contour plots, maybe add histograms. In other words, I would play around with it.

Graph builder sort of automates that process. You can interactively add data to the x-axis, multiple sets of data to the y-axis, separate plots with the same x-axis, separate sets of data on the same plot, etc. If you don't like what you see, remove a set of data, or graph it differently. It's helped me out with two specific problems already, which makes it worthwhile in time savings alone.

I don't work for SAS, I don't get any compensation from them. I just really like the software.

Instrumentation Finder website

There's a relatively new website called Instrumentation Finder. To quote from their intro page:

This site aims to provide a one stop shop for any and all Instrumentation requirements whilst providing all users with the option to source equipment from overseas suppliers outside their normal purchasing reach.

I've tried it out some and it is a) heavily biased towards UK and Europe suppliers (they say that is changing), and b) still a work in progress. But I certainly like the idea of a website specifically for finding instrumentation manufacturers and their products.

FIRST robotics

I posted over a year ago about FIRST Lego League and how my oldest son liked it. Well, now my second son is in middle school and decided to join the robotics club as well. They had their regional competition a few weeks ago and just barely missed the cutoff for the state championship.

He was disappointed about it, but I know he had a lot of fun. From an engineering point of view, I thought the best part was the night before the regional competition. I stopped by for the last half hour of their planning session and got to see them toss ideas back and forth, debug code, and try out different ideas for solving a tough challenge. In other words, it was a lot like a group of engineers solving a problem. Cool.

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.

Climate Change

So I had signed myself up for Blog Action Day, on October 15th, and then forgot about it. The topic was Climate Change, and I had a vague idea of what I wanted to discuss. But this past week I've been helping my son with a big term paper, running around town running a lot of errands, and it slipped my mind. It didn't help that it had been over a month since my last post on the blog. But better late than never.

I met a fellow grad student back in 1990 that was planning to do his dissertation on climate modeling. Dr. Hansen gave his famous senate testimony about global warming in 1988, and this was now a hot topic in scientific circles. This particular student was fascinated by all the mathematical modeling involved and how so many different aspects of physics and chemistry had to be involved.

I'll never forget a long conversation we had about the changing climate. Even then he thought it was more important to call it climate change instead of global warming, because he believed that the key change was the increased amount of energy in the system. The planet heats up, sure, but heat is just energy, and all that energy can go into other things as well. The oceans heat up, the air heats up. This leads to more storms, deadlier storms, changing weather patterns, etc.

It all sounds sort of prescient nowadays.

Test Engineer of the Year

Test and Measurement World may appear to be yet another trade magazine , and sometimes they are. But they also do great things for the test engineering community, like the salary survey. Their annual Test Engineer of the Year award is another one of those community service sort of things. Pretty cool.

So, go read about the past finalists and winners. Then recommend someone you know who deserves the award. Then vote.

Statistics is cool

During vacation I read this article about statistics being the job of the future (also, refer to this talk by the chief economist at Google). I've posted a lot about statistics before (here, or here, or there for example), and I seem to use it a lot in my job, especially when dealing with large sets of data on a lot of DUTs. So that article naturally jogged my brain to recall a conversation I had last month with some other engineers at work.

The field of computational physics has existed for a long while - at least as long as relatively cheap computer time. The premise of comp. phys. is that many of today's physics problems don't lend themselves to elegant mathematical solutions. You have to apply numerical techniques to simulate, prove, or disprove a theory. When I was in grad school two decades ago I knew a post-doc whose entire job (at least while I knew her) seemed to consist of running Monte Carlo simulations on potential collision results at Fermilab: computational physics.

But let's go one step further. Decades ago one of my favorite books was the award winning Startide Rising by Dr. David Brin. One premise of the novel was that, while other alien races used brute force numerical calculations to figure out engineering, the upstart humans were pursuing solutions using mathematical proofs, theorems approximating effects, etc. Good stuff, but I suspect that the aliens are right. I predict that as science progresses, more and more discoveries will be made using powerful computational tools, not "elegant mathematical formulas."

I'm not sure how much that last, rather speculative paragraph has to do with test engineering. But if scientists can theorize about something, sooner or later it has to be tested. Until then it's just theory. And I think that testing will increasingly involve statistics.

2009 Salary Survey

The 2009 TMW Salary Survey came out this month. I've written about their survey before, but it's always interesting to take a yearly peek into how everyone else is doing.

Interesting tidbit #1: The highest ranking for "New technology learned about in the last 2 years" was clearly RF Measurement (38%). I guess that makes sense when considering the prevalence of WIFI and Bluetooth devices.

Interesting tidbit #2: There is still no breakout of salaries by geographic area. Too bad.

Interesting tidbit #3: The highest paid group of engineers are those with 30+ years of experience, followed closely by the 20-24 years group and then the 25-29 group. To make sure this wasn't a fluke, I checked the 2008 and 2007 surveys as well - they had similar results.

What does that last tidbit mean? I considered that question for a while & ended up with two guesses:

Optimistic view: In some professions the older you are the less you are worth. In test engineering, the more experience you have the more valuable you are. The engineer's programming skills, knowledge of test circuitry, etc., do not go out of style or get stale.

Pessimistic view: Most engineers are forced out of the profession as they age. The ones that are left are the exceptional few with skills not easily replaced, so they can command higher salaries.

For obvious reasons, I prefer the former over the latter.

New test magazine

Well, I said in my last post that I was going on vacation. But this post was already mostly written, so what the heck.

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

Keithley is sponsoring a new magazine called Project Test. According to the press release, it is a "unique 32-page electronic magazine edited for test and measurement engineers." In my opinion, the jury is still out. It's obviously meant as a marketing tool - most of the articles in the first issue are written by Keithley employees and spotlight Keithley equipment. I'm not sure if that fits the press release though.

There's nothing inherently wrong with this sort of self-marking document, if it's done right. Hewlett Packard did a good job at this with their Journal this back before the split. The articles were usually written by HP engineers (sometimes in conjunction with marketing), and they often conveyed a great deal of solid technical detail. That is the standard I would hold Keithley to.

Getting LabVIEW certified

Well, I've decided to get my Certified LabVIEW Developer (CLD)... certification? diploma? license? Regardless, I plan on shelling out the money and taking the test probably by the end of the year.

A couple of years ago I was ambivalent about certification. But I've modified my opinion for the following reasons. First, NI now offers a CLD renewal test, which was one of my original gripes. Second, the CLD test used to be one long test - half written and half practical - and it seemed like overkill to me. Now the written part is given as a separate test - Certified LabVIEW Associate Developer (CLAD) - and is often offered as a free test. Third, I took the CLAD a couple months back and passed it easily. I figure I'm halfway there already.

Finally, given the state of the economy I think it makes good sense to get recognition for my skills. Another engineer friend of mine just lost his job, and that sort of thing reminds you to be prepared in case you need to find another employer.

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

Over the next few weeks I'll be taking some extended vacation time. I have at least one or two other posts partially written, but I may not get to them until late August or even September.

Test gear history

I found this picture back in April and thought cool. It looked like it could come from a Hollywood period movie yet it was real. I noted the page for future reference and then forgot about it.

My current company is in a huge building that's over a century old. It was one of the first buildings in the world to use reinforced concrete, and it used to be the headquarters for the United Shoe Machinery Company. The halls are decorated with little mementoes of the company's past: poster-sized pictures 50 to 100 years old, historical vignettes of life in the company's heyday, old-style shoes, and equipment used on the manufacturing line. One day I stopped to stare at this display.

It's an old poteniometer used for equipment calibration. So I dug around online and found out that it was manufactured by Leeds & Northrup in Philadelphia - evidently they were quite the test and measurement company back in the day (see this or this).

I connected this piece of equipment with what I'd seen back in April and thought a lot about old test equipment, where it goes, and the history of the equipment and the people who make them. Does the equipment eventually sit on a shelf for decades before it is tossed (or sent to theSmithsonian)? Do the people who devote so much time & effort to create this equipment get any recognition (other than a brief summary on Wikipedia)? Normally I'm not a very reflective or pensive person. But sometimes you just have to think about these sorts of things.

LAVA flows once more

The LAVA (Labview Advanced Virtual Architects) website is back up and running after a several month absense. While I don't read that forum on a regular basis, it is definitely a useful resource. Along with the NI-hosted forums and the Info-LabVIEW mailing list, it's part of the top three online resources for programming with LV.

I'm glad to see it's back up.

Two year anniversary

So, it has now been about two years since my first post. When I recognized my one year anniversary, I noted that I'd posted on average once a week for a year. Well, I haven't been quite as prolific since then: only 32 posts. But still, considering the job changes the past year, that schedule is not too bad, considering I do this "just because."

There was an article a few weeks ago in the New York Times about blogs getting abandoned after people lose interest in maintaining them. It's an interesting piece, but I expect it's probably a retread article of what happened a decade ago when there was a rush of people creating their own webpages, and then they gave up on them. I know I did that at one time.

But two years... it's not abandoned yet.

Apple secrecy vs. collaborative transparency

I wrote about a month ago about intranets & collaborative software. That post also referenced a Wired magazine article about companies becoming more transparent. Well, this past week the New York Times ran a tangential article this past week: the main thesis was that most companies are becoming more open, except Apple. It's a good read.

Tools every test engineer needs

The May 2009 issue of Popular Mechanics has a very nice article listing the 50 tools every man needs and how to use them.  I enjoyed reading the article, and certainly learned a few things - for example, WD-40 stands for "Water Displacement 40th attempt" since it took 40 tries to get the formula right.  And this article started a train of thought.

What are the essential tools a test engineer needs?  I'm not talking about industry-specific measurement equipment, but rather tools that span those industries.  So I combed through the list of tools I've used at multiple companies, tools I commonly see in labs, and of course Google.  I also included software packages as tools - that's part of how engineers roll in the 21st century.  

So below I offer, in no particular order, my personal top list of tools every test engineer should have (or at least know how to use).

Digital Multimeter

The first that comes to mind is the DMM, the essential tool for troubleshooting electrical connections.  My personal favorite is the standard Fluke model.

Leatherman

I'm surprised the Popular Mechanics article didn't list this as an honorable mention.  I've already written about its usefulness.

Power Supply

A good utility power supply is essential to any lab.  My personal favorite is the Keithley 2400.

Labview

You have to have some way to automate data acquisition and storage.  I've used Visual Basic, C - heck, I've even used Fortran.  But like it or not, Labview is designed to be used for test engineering, and it shows.

Statistics Package

Once you get the data, you need a way to analyze it: graphing beyond just the basic X-Y axes, SPC work, trending.  A good spreadsheet package will get you most of the way there, but for more detailed work you may need something more like Matlab or Minitab.  My personal favorite is JMP. 

Oscilloscope

Almost as important a troubleshooting tool as the DMM, oscilloscopes were popularized by Tektronix.  I still think they make the best ones.

Video Microscope

This one is obvious.  Sometimes you need to zoom in and take a picture.

TEC & Thermister

I can't count the number of times I've had to use a TE cooler (sometimes coupled with a fan assembly) to adjust or control temperature of a DUT.  They're easy to use, small, have no moving parts, and relatively maintenance free (unless you fry it).

Function Generator

Similar to the power supply, this is a tool a test lab has to have, or it's just not a test lab.

Well, there's my list.  Feel free to suggest more if you want.

Startup: one year anniversary

I've been with my current startup company for a year now.  When I first joined, I posted about whether "startup specialist" was a specific subset of test engineering.  I hedged on the answer to the question back then - today I'll claim yes.  I'll try to explain why.

Here are the four skillsets I thought a test engineer at a startup needed: 

1)  software skills
2)  general knowledge of mechanical and electrical engineering

3)  data storage and analysis ability

4)  people skills

Over the past decade I've worked in 4 engineering startups where I was the only (or first) test engineer.  In the three startups before this latest one I used #1 & #4 always and #2 & #3 about a 1/3 of the time.  But in this latest startup I've had to rely on all four extensively.  For example:

• I've learned more about databases in the past year than I ever thought I'd need to.  
  
• I've stretched out my knowledge of semiconductors quite a bit.  
  
• I have to write some form of code (whether it is LV or just scripting for data analysis) practically every week.
  

These are skills that I never exercised extensively as a test engineer in a bigger company.  So, I think that proves my point.

LabVIEW Developer Education Day, 2009

I attended the LabVIEW Developer Education Day last week in the Boston area.  It was pretty good, although one of the presentations by a non-NI person was partly an advertisement for OpenG tools.  That was okay with me, since I've used them in the past.

If you are interested, the presentation slides are here.

I know someone who has an Emmy

I just found out this week that a friend of mine received an Emmy.  

There's a loaded statement.  But no, there was no red carpet stroll - just a certificate in the mail for work he did back in the mid 90s to support testing ATSC (Advanced Television Systems Committee) standards for HDTV.  He had no idea it was coming until they contacted him right beforehand.  Evidently it was part of the publicity push when HDTV was supposed to be released this past February.

But still, that's pretty cool.  Congratulations, Chuck.

Intranets and collaborative software

The post I wrote about HP/Agilent a couple weeks back started me thinking about what that experience was like.  Then I recalled something that I had started writing well over a year ago.  This is what resulted...

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

When I worked at Hewlett Packard back in the late 90s, I was told that HP had the world's largest intranet.  I'm not sure how true that is, although I did find this press release from 1996 where they make that claim.  I do know that all groups in my division were expected to create and maintain an internal website.  That website was in turn linked to department websites, division websites, etc.  Employees could also create their own websites & link them to their group's website.  I was the admin for my group's site.

It was a great tool for three specific reasons:

Information Repository - While I was there, our group started using the website as a convenient way to store information online.  Plus, guess which is easier: a) Tell someone to go to your group's website, click on "documents", and download the test report; b) direct them to H:\Shared\public-files\bfg2000\documents\reports\new-test-report-v1.1.doc

Reasearch - This was back before Google was commonly used (although I was partly hired because my manager had found me online via Google), and Wikipedia wasn't even invented yet.  There were search tools that HP had specifically for digging up info on it's intranet, and you could find a lot of technical information that way.  I downloaded bits of code, internal specs, and other useful bits of info that HP employees had loaded onto the intranet.

Status Information - Testing schedules, group members, who is working on what project, milestone schedules.  All these things were listed on our website.  Managers could go there directly and get that information without bugging the engineers.

Flash forward several years.  I read an interesting article in Wired magazine about company blogs and sharing information while on a plane flight to Denver.  When I got back home I talked with my company's CEO about starting up an internal company website that would include blogs and other information from the various departments.  I had some success - by partnering with our IT manager, we introduced Sharepoint to the company and got people to start using it.

At my current employer we use Sharepoint extensively, and it's a good tool for the three reasons I wrote above and then some.  Other good reasons for having this sort of tool include a) it can be used as an inexpensive document revision tool, b) postings can start discussions about technical issues, and c) you can post general information (HR policies, company calendar, etc.) there.

I guess what I'm trying to say is this: if your company doesn't already use a tool like this, talk to your manager, director, or CEO about getting one.

Agilent and Hewlett Packard - So long, and thanks for all the fish

Martin Rowe at Test & Measurement World wrote a nifty blog post about how younger people don't know that Agilent used to be HP.  It generated quite a few comments.

Until I read that post, I didn't realize that it has been ten years since that happened.  Officially, the split was completed on November 18, 1999, after the IPO.  But for everyone working there, including myself, it happened on March 2nd of that year.  I had heard a rumour that something like that was in the works, and some of the oldtimers there said that a split had been rumoured for several years.

I worked at the Santa Rosa, CA, facility on Fountaingrove Drive.  It was a beautiful facility, and counting the manufacturing facility in nearby Rohnert Park, HP employed several thousand people there in Sonoma County.  As I recall, the mood of nearly everyone I talked to was somber, and yet glad that they were going to be with the "real" HP - the test and measurement side.  There was a LOT of pride there.

So, here's a (belated) happy 10th Anniversary to Agilent Technologies.  I hope they have at least a dozen more of the same.

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.