One of the major pain points in my day-to-day use of LabVIEW (which I love) is building stand-alone applications. I suspect that the reason this is so painful for me is that (in addition to my use cases being fairly advanced) most of the developers at NI who are on the LabVIEW development team probably don't build applications using LabVIEW -- they are not eating their own dog food.
For example, LVOOP (native LabVIEW Object Oriented Programming) dynamic method overriding requires VIs of the same name, but it is impossible to store two VIs of the same name inside an EXE? How could this feature conflict possibly happen? I suspect that nobody actually tried to build an application that used LVOOP until well after the feature was implemented. What's even crazier is that NI was working on this feature for many years, before it was released.
As time goes by, more people within NI are developing code in LabVIEW on a daily basis. However, I'll bet that most of them never actually use the application builder to build stand-alone applications, since most LabVIEW code is shipped in source form and never gets "built" -- it's just one big, monolithic reuse library.
So, I'd like to challenge developers at NI to find ways to incorporate stand-alone (built) LabVIEW applications into their internal systems and processes. It will make a huge difference to your customers.
I'll have you know that I'm committed to eating my own dog food, too. At JKI, we work very hard to use our own products in a variety of ways:
- EasyXML is being used inside VI Package Manager (and other JKI products and projects), for reading and writing XML files.
- VI Package Manager (VIPM) is used to install EasyXML, as well as manage the LabVIEW configuration needed to develop and build EasyXML (and every other JKI product and project).
I should close by saying that I know some of the people who work on the LabVIEW application builder and LVOOP and they are all very nice/smart people who are very competent LabVIEW developers and software designers. The only problem is that they are probably not eating their own dog food. NI has stated that they are committed to this, so I want to make sure that this is one area they do not neglect
I recall an NI engineer at NIWeek a couple years ago describing the sound of “several dozen foreheads simultaneously hitting their desks” when it was discovered that override VIs would have to be stored outside the EXE.
Also, I raised a similar question (”Honestly, how may developers inside NI use the App Builder, and what do they use it for?”) at my local NI Dev Day a few weeks ago. I got an answer along the lines of, “We’re using it more and more every day.” I don’t remember it exactly, because it was really more of an accusation than a question to begin with, and the true answer is clearly, “Not enough.”
Good points Jim!
That reminds me a war story from back in the day…
Ken Olsen (owner and founder of Digital Equipment Corp.) gathered all of his top managers togther and demanded that they assemble a computer system using only the instructions available when they were shipped.
It was not very long until the hardware got much easier to work with.
Ben
Hi
I hope NI will abandon the LLB structure they are using in the exe-file or at least add folder support in the a LLB, this will make it possible to store everything inside the exe-file.
One other painful thing I have is that a quite large application, with lot of classes and lvlibs, it takes me more then 30 minutes to build an executable and during that time I can’t use my computer for something else, since LabVIEW uses all my resources.
Cheers,
Mikael
Justin: Regarding, “foreheads simultaneously hitting their desks”, that sounds a lot like what happened when I found out
Ben: Yes, these concepts are timeless. Thanks for sharing that story. I’m looking forward to sharing some stories about about how we’re eating our own dog food at JKI, soon.
Mikael: It’s too bad you can’t use that 30 minutes to catch up on LAVA. Actually, I’ve worked on an application that takes 15 hours to build! And, it took much longer than that before we did some build optimization (removing some type definitions that were inside the class data cluster). Our solution to the long build time was to have a dedicated build machine with quad (4) core 2 duo processors. But still, this is very impractical — we can’t wait 15 hours to know if a build was successful.
It is not only that LVOOP things won’t work if you build an application. Also a lot of Properties won’t work any more after you build an application and that changes with every Labview version. And the superstar of all the vi’s that won’t work is the Current Path VI that never was good.
And that’s why we love OpenG, Tom see here.
On the builder issue, what happens during those 15 hours? That are a lot of computations.
Ton
Jim,
15 Hours, it would be good if you could use a cluster server like this one:
http://helmer.sfe.se/
Cheers,
Mikael
Jim:
Interesting point, for years I have maintained the belief that NI doesn’t hire enough from industry, since they typically hire right out of college. People that haven’t practiced, seldom preach an accurate message.
Do you think this hiring practice could be one of the root causes? Just curious about your opinion.
Matt: Yes, you’re probably right. NI typically doesn’t pay for experience engineers — they prefer to hire right out of college and have them develop their experience within NI. This is what makes eating their own dog food so important. It would probably benefit NI greatly to hire outside people who are very skilled users of NI’s tools, however, these individuals are, at the same time, both (1) expensive to hire and (2) have an enormous value to NI, when left “out in the wild”, where they directly purchase NI’s products or facilitate the purchase of NI’s products through integration services.
Interesting point Jim. I wouldn’t have thought about how hiring an engineer from the industry might remove a customer. Valid and certainly an eye opening perspective. Thanks!
Matt: Another interesting thought is that an engineer who is highly skilled in using NI products might be more valuable to NI when they are working for a large company vs. an NI alliance partner. The reason being that they can more effectively evangelize NI products within that large organization and they probably have a big stack of purchase orders