Elite

[crossrulz]

---

RogerIsaksson wrote:

The NI SW test team(s) seem to be in desperate need of competent workers.

I mean, after all, NI pushes testsystems, but fail to test their own stuff? Why?

/Roger

---

Actually, they do quite a bit of testing.  But there's only so much you can do.  It takes time to test code.  And somebody has to write the test algorithms.  This is far from a simple task.

[User002]

---

@crossrulz wrote:

---

RogerIsaksson wrote:

The NI SW test team(s) seem to be in desperate need of competent workers.

I mean, after all, NI pushes testsystems, but fail to test their own stuff? Why?

/Roger

---

Actually, they do quite a bit of testing.  But there's only so much you can do.  It takes time to test code.  And somebody has to write the test algorithms.  This is far from a simple task.

---

"We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too."

/Roger

[Ben]

back to the topic...

One of the drawbacks of being a well-seasoned devloper is you out-grow your support.

NI's AEs come in multiple flavors.

They start out with the ... 3 months of everything NI school then they get a chance to answer Q's on the forum or answer phones for the basic support line.

Some are damn good and you remeber their names and they serve you well. Others are looking to mkae lots of money and sell sell sell. When I run into them, I usually get myself into trouble and the next thing you know I am appoligizing to someone.

There was one AE that I had to exaplin what "zero time" was in LV. I asked him if he was premier support and he said yes. I went outside to scream after that call. Realizing he had blown it he quickly wrote a nasty gram that made it to my boss acusing me of something or other that I did not do. His name is burned into my memory. I can forgive but I will not forget who burned me. The good news is he got promoted out of being an AE and as long as I don't go to NI Week, I should never run into him again.

So in my bull-pen I call it "Support roulette" spin the phone and see who you get. If they are a bozo, say thank you and hang up. Call back in and try again.

Again there are some sharp AEs. So don't waste your time on the others.

That is just my two cents,

Ben (with a bad attitude)

[User002]

Okay, so far on the NI bozo side we have:

#1 NI AB suck with RT & LVOOP, no beating around the bush here.

#2 NI lack effective testing, SW bugs as large as Nimitz sails right through validation

#3 Bozo AE's that need to go back to basic LV 101 training

#4 Forum trolls like me flipping people off

Now adding some balance to this, thus for the NI elite side:

#1 G is pretty spiffy.

#2 NI HW is solid. 

#3 Ninja AE's that make a difference

#4 Forum champs such as Ben, et. al. Here's one's dedicated for you guys: LINK. 

Br,

/Roger

Edit: and yeah, keep going with this list.. 

[altenbach]

---

@User002 wrote:

#2 NI lack effective testing, SW bugs as large as Nimitz sails right through validation 

---

NI does extensive testing of every daily build. For example here's a quote from this page:

"For each release of LabVIEW, the LabVIEW development team maintains an entire farm of test computers running daily benchmarks for run-time performance. These benchmarks are largely computational tests focusing on the execution of LabVIEW block diagrams."

Any direct bug will be definitely caught, classified for severity, and scheduled to be fixed according to the expected impact and available resources. Of course if there is a tertiary interaction that only shows up if multiple unusual conditions align themselves, it might slip through (example: AMD FX processors, more than 16 cores (which is actually due to a problem in the intel math kernel library), etc.). If your programming work or hardware is somewhat unusual, you are strongly encouraged to sign up for the next beta so problems can be identified and fixed before public release. The LabVIEW developers are an impressive bunch and every new release is faster and more stable overall (see also). I am always amazed how well things actually work. 😉

The number of possible hardware combinations or LabVIEW programs probably exceeds the number of atoms in the universe. It is simply not possible to test all scenarios, even with unlimited resources. There is not a single piece of software on earth that is without bugs, and that is just a reality. Even your "hello world" program might crash if the next processor generation comes out or you have a certain MB chipset. Once software has asymptotically matured to a point where there is exactly one bug left, it will probably be obsolete. (There is a fundamental law that the last bug cannot be found) 😄

Whenever you run across an issue, make sure to submit a detailed bug report that can be reproduced.

So, what would you suggest? Quadruple the number of qualified developers (first, you need to find and train them!!!) and quadruple the cost of LabVIEW at the same time? Maybe not. 🙂

[User002]

Well, where do I begin?

Scrap that slow centralized POS VCS (Perforce) they are using and switch to a more modern one, for example GIT/Hg, so that bugfix/feature iteration time goes down. Do static code analysis such as with Coverity. Yes, hiring competent programmers cost. The alternative you are suggesting cost even more.

I stated that NI need more effective testing and fast response when bugs are found and reported. For example the ignored AB performance bug(s) I have been posting in the forums and expired SR, and the #CAR regarding dynamic dispatch execution slowness that for example you more or less slammed me down for, that same Nimitz-class performance bug sailed past without so much as a blip on the radar.

Well, I could go on, but I chose to not.

My point still holds.

Br,

/Roger

[GregFreeman]

---

@Ben wrote:

One of the drawbacks of being a well-seasoned devloper is you out-grow your support.

... 

Again there are some sharp AEs. So don't waste your time on the others.

---

Ben,

I completely agree, and although I get premier support also, I still start every conversation with "I did this and this and this and this and none of it worked". That way I don't spend the first 15 minutes getting suggestions to do things which I've already tried. I haven't run across much incompetence, but sometimes there is a knowledge gap. This is to be expected, as you can't expect every person that answers your call to know everything about everything so they can answer any question that comes their way. I always appreciate it when an AE says "let me bring in my coworker."  I don't take this as an admission of incompetence, but instead I appreciate them admitting they may not know. It saves both my time and theirs, and often both parties end up happier. 

Also, ever gotten a call from a coworker onsite telling you they are having a problem? When this happens I often find it to be incredibly difficult to troubleshoot, even when I have the code in front of me! So, I can't really blame any AEs for sometimes needing to take a "try this then this" method rather than giving an explicit answer. Furthermore, yes it's their job, but many problems I'm sure they get calls about are boring, mundane, and really wouldn't interest any engineer. Trying to force yourself to solve an uninteresting problem is difficult (at least it is for me) so putting my all into it  is admittedly difficult (possible hiring managers please ignore the previous sentence). So that's my rant; while I also can get frustrated, I try to take things in perspective.

To the OP, maybe there are things that can be done better; every company has those things. But I would hardly call the NI programmers "incompetent." It is easy to make suggestions that would obviously make things easier, but for a billion dollar company that may have had a specific process in place for many years, the wheels turn slowly. After working at a large, fortune 500 company, which I left due to in part by my suggestions for improvement falling on deaf ears, it makes me think that it is not a symptom of NI, but more a symptom of being a large entity. While this isn't necessarily an excuse, it is important to remember this. 

[User002]

---

 To the OP, maybe there are things that can be done better; every company has those things. But I would hardly call the NI programmers "incompetent." It is easy to make suggestions that would obviously make things easier, but for a billion dollar company that may have had a specific process in place for many years, the wheels turn slowly. After working at a large, fortune 500 company, which I left due to in part by my suggestions for improvement falling on deaf ears, it makes me think that it is not a symptom of NI, but more a symptom of being a large entity. While this isn't necessarily an excuse, it is important to remember this. 

---

Of course there are incompetent programmers and dysfunctional teams with for example bozo "senior architects" spouting one crappy, slow and bloated "framework" and implementation after the next. After all, it isn't Google or Apple we are talking about here. 

Are NI senior management still in touch with reality or perhaps they are operating blindfolded? (as only Scott Adams strikingly can illustrate with his cartoon)

Br,

/Roger