topic Elite in BreakPoint

Elite

User002 — Fri, 12 Oct 2012 07:42:20 GMT

Okay, this one might be a little controversial.

My offtopic question is regarding the NI Engineering (in?)competence

We all know that the HW and LabVIEW G people mostly are pretty godly elite, with mostly only minor screwups from time to time.

Can the same be said about the Appliction Builder, specially, and addon team(s)?

That POS (AB specially) have caused me some serious rages and fits over the years.

Any daring thoughts?

Br,

/Roger

Re: Elite

PaulG. — Fri, 12 Oct 2012 11:54:50 GMT

Most of my heart-stopping events have been while building applications, but I won't go so far as to blame the AB itself all the time. I cause most of my own trouble, usually when I don't follow "best practices" and don't build my application daily. Far fewer headaches if I stay on top of things and only have to track down one problem at a time.

Re: Elite

Cerati — Fri, 12 Oct 2012 12:29:31 GMT

Sorry offtopic, but when seeing the title - was expecting to read stories of the glorious space battles and dangers of the interstellar trading...

Re: Elite

User002 — Fri, 12 Oct 2012 12:44:18 GMT

@Cerati wrote:

Sorry offtopic, but when seeing the title - was expecting to read stories of the glorious space battles and dangers of the interstellar trading...

For all youngsters. Here's the wikipedia link:

http://en.wikipedia.org/wiki/Elite_(video_game)

Br,

/Roger

Re: Elite

Intaris — Fri, 12 Oct 2012 14:16:38 GMT

Ooh the memories, the sweet sweet memories.

Blue danube all the way.....

Shane

@User002 wrote:

@Cerati wrote:

Sorry offtopic, but when seeing the title - was expecting to read stories of the glorious space battles and dangers of the interstellar trading...

For all youngsters. Here's the wikipedia link:

http://en.wikipedia.org/wiki/Elite_(video_game)

Br,

/Roger

Re: Elite

altenbach — Fri, 12 Oct 2012 15:52:13 GMT

Well, I don't have any problems with the application builder. It works perfectly for me... 😄

From looking at your other posts, it seems like most of your problems are related to RT, which I don't (yet) use. Also, remember that you can speed up the builds if you don't delete the cache or select "clean" from the right-click menu. In a big project, it is unlikely that everything needs to be redone from scratch.

Re: Elite

User002 — Fri, 12 Oct 2012 16:23:45 GMT

@altenbach wrote:

Well, I don't have any problems with the application builder. It works perfectly for me... 😄

From looking at your other posts, it seems like most of your problems are related to RT, which I don't (yet) use. Also, remember that you can speed up the builds if you don't delete the cache or select "clean" from the right-click menu. In a big project, it is unlikely that everything needs to be redone from scratch.

I recall back in the day when LVOOP was new and I tried the AB on some classes with inheritance, it didn't exactly go too well with overridden methods.

Even the usually proud NI folks looked a little embarrassed back then. It's mostly forgotten now, though, and pride is restored.

If they would just speed it up and add some more verbose error messages and debug down the most odd AB build error issues and bugs.

6h+ for a build (that also happen to error out) from scratch on a RT target is a bit too much, I think we can agree on that?

Br,

/Roger

Re: Elite

User002 — Fri, 12 Oct 2012 16:40:23 GMT

Okay, here's one.

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?

It's truly baffling! just bloody install teststand and start to write tests.

How hard can that be?

Br,

/Roger

Re: Elite

altenbach — Fri, 12 Oct 2012 16:43:32 GMT

Are you looking for a job?

Re: Elite

User002 — Fri, 12 Oct 2012 16:44:48 GMT

@altenbach wrote:

Are you looking for a job?

I am already working for NI as a tester.

Why do you wonder?

Br,

/Roger

Re: Elite

crossrulz — Fri, 12 Oct 2012 16:53:46 GMT

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.

Re: Elite

User002 — Fri, 12 Oct 2012 16:59:19 GMT

@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

Re: Elite

Ben — Fri, 12 Oct 2012 19:29:44 GMT

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)

Re: Elite

User002 — Fri, 12 Oct 2012 20:18:56 GMT

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..

Re: Elite

altenbach — Sat, 13 Oct 2012 00:18:42 GMT

@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. 🙂

Re: Elite

User002 — Fri, 12 Oct 2012 21:54:27 GMT

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

Re: Elite

GregFreeman — Sat, 13 Oct 2012 00:40:34 GMT

@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.

Re: Elite

User002 — Sat, 13 Oct 2012 06:29:06 GMT

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