tag:blogger.com,1999:blog-8187687005139407155.post8402644534749041388..comments2011-01-01T11:31:42.503-05:00Comments on Choice Management: Why people don’t use LabVIEW?William L. Weaverhttps://profiles.google.com/106992071744711893668noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-8187687005139407155.post-18999845047269955462011-01-01T11:31:42.489-05:002011-01-01T11:31:42.489-05:00Dear Professor Weaver,<br>I am a consultant, speci...Dear Professor Weaver,<br>I am a consultant, specializing in LabVIEW development since 1992. I too have pondered this question for many years and have raised it at user meetings, private discussions and with NI.<br>- First of all I have to politely disagree with the assertion. People DO use LabVIEW for non data acq projects. For example, the hospital bed management system, "Bed Management Dashboard" (BMD) by Eclipsis (formerly Premise Development) was written in LabVIEW. This is a thick client, MSSQL based hospital management system with several hundred client stations in a typical installation. I worked on it off and on for several years, including re-architecting the main server and making it a proper Windows Service, in my last assignment. A typical installation costs several hundred thousand.<br>The question really is, "why don't they use LabVIEW more, or first?"<br><br>- The corollary question is why doesn't NI market and promote it for more mainstream applications?<br>- The main reasons NI marketing doesn't target more mainstream applications is competition and support. NI is the 800 lb gorilla in the data acq and control niche. They don't want to attract more attention from Microsoft et al, by going more into the text domain where there is a lot more entrenched competition. Support for an engineer or scientist operating hardware is within NI's expertise. Advising an investment banker coding up the next Wall Street Web based data mining app to predict market swings, is not. We discovered this when we were developing BMD.<br><br>- Another main discouragement to LabVIEW is simple fear and prejudice. Often times the more senior person(s) with final implementation influence are unfamiliar with *proper* development of large complex apps in LabVIEW. Choosing LabVIEW as a development platform would mean giving up a large part of their control of a project and entrusting that others who are experts in LabVIEW development. This happened a couple of times in the astronomy arena. Several years ago I worked on the SOAR telescope (in LabVIEW), including the camera instrument controllers. We developed a package called ArcVIEW (Array Controller in LabVIEW) based on the Leach SDSU-II hardware. Later, the NOAO instrument group was developing a new controller and software system to be called MONSOON. Naturally SOAR proposed ArcVIEW as the software. The review of this went well until a very senior astronomer/developer came into the picture. He immediately began shooting down LabVIEW, making no attempt to hide the fact that he was prejudice against it's use simply because he wasn't an expert, not about any real shortcomings of LabVIEW, other than that it is "expensive and proprietary" and therefore should be disallowed in favor of GNU C tools, TclTk, etc. This was hogwash, as the same man promoted use of SolidWorks ("expensive and proprietary") to design the optical hardware rather than open source CAD tools/methods. His opinion finally carried the day and MONSOON was developed with text.<br><br>- Lastly, LabVIEW often gets a bad rap because people try to do things with it that are way way above their skill level. They see that you can do things quickly in it that they wouldn't even consider attempting in a text/OOP lanaguage. They then charge ahead without doing upfront design. They don't apply proper software engineering discipline and practices on non trivial projects and when they end up creating spaghetti even faster than their text programming colleagues do and the project fails, then LabVIEW gets the blame. "Texties" then point to this as ammo to shoot down LabVIEW for consideration in other, more generalized, non data acq projects.<br><br>- However, with LEGO MindStorms, FIRST Robotics and other educational outreaches teaching this generation of students the benefits data-flow programming, I think it is just a matter of a few more years and you will see a large upswing of LabVIEW use outside of it's current niche.Michael Ashehttp://www.imaginatics.netnoreply@blogger.comtag:blogger.com,1999:blog-8187687005139407155.post-43302040782841147842011-01-01T11:31:42.158-05:002011-01-01T11:31:42.158-05:00Hi Michael,<br><br>Thanks for your thoughtful comm...Hi Michael,<br><br>Thanks for your thoughtful comments. I have similar stories from my days developing systems for the Air Force. <br><br>Things take time... and I guess 25+ years for LabVIEW to go mainstream is not too long to wait. It's just that so many other things in the hardware and software realm catch on so quickly that I'm still surprised that LabVIEW is not included in intro to programming courses more often (maybe it is... I haven't done a study).<br><br>I'm sure you share my frustration... as a person that spends so much effort optimizing systems, it is painful to see a new project start off in a niche text language rather than be completed in 20% of the time in LabVIEW.<br><br>Wire on! =]William L. Weaverhttp://www.blogger.com/profile/17708550957021633126noreply@blogger.comtag:blogger.com,1999:blog-8187687005139407155.post-46125962708342748272009-12-27T23:29:55.851-05:002009-12-27T23:29:55.851-05:00Hi Michael,
Thanks for your thoughtful comments. ...Hi Michael,<br /><br />Thanks for your thoughtful comments. I have similar stories from my days developing systems for the Air Force. <br /><br />Things take time... and I guess 25+ years for LabVIEW to go mainstream is not too long to wait. It's just that so many other things in the hardware and software realm catch on so quickly that I'm still surprised that LabVIEW is not included in intro to programming courses more often (maybe it is... I haven't done a study).<br /><br />I'm sure you share my frustration... as a person that spends so much effort optimizing systems, it is painful to see a new project start off in a niche text language rather than be completed in 20% of the time in LabVIEW.<br /><br />Wire on! =]William L. Weaverhttp://www.blogger.com/profile/17708550957021633126noreply@blogger.comtag:blogger.com,1999:blog-8187687005139407155.post-33934607019213206682009-12-24T12:59:38.075-05:002009-12-24T12:59:38.075-05:00Dear Professor Weaver,
I am a consultant, speciali...Dear Professor Weaver,<br />I am a consultant, specializing in LabVIEW development since 1992. I too have pondered this question for many years and have raised it at user meetings, private discussions and with NI.<br />- First of all I have to politely disagree with the assertion. People DO use LabVIEW for non data acq projects. For example, the hospital bed management system, "Bed Management Dashboard" (BMD) by Eclipsis (formerly Premise Development) was written in LabVIEW. This is a thick client, MSSQL based hospital management system with several hundred client stations in a typical installation. I worked on it off and on for several years, including re-architecting the main server and making it a proper Windows Service, in my last assignment. A typical installation costs several hundred thousand.<br />The question really is, "why don't they use LabVIEW more, or first?"<br /><br />- The corollary question is why doesn't NI market and promote it for more mainstream applications?<br />- The main reasons NI marketing doesn't target more mainstream applications is competition and support. NI is the 800 lb gorilla in the data acq and control niche. They don't want to attract more attention from Microsoft et al, by going more into the text domain where there is a lot more entrenched competition. Support for an engineer or scientist operating hardware is within NI's expertise. Advising an investment banker coding up the next Wall Street Web based data mining app to predict market swings, is not. We discovered this when we were developing BMD.<br /><br />- Another main discouragement to LabVIEW is simple fear and prejudice. Often times the more senior person(s) with final implementation influence are unfamiliar with *proper* development of large complex apps in LabVIEW. Choosing LabVIEW as a development platform would mean giving up a large part of their control of a project and entrusting that others who are experts in LabVIEW development. This happened a couple of times in the astronomy arena. Several years ago I worked on the SOAR telescope (in LabVIEW), including the camera instrument controllers. We developed a package called ArcVIEW (Array Controller in LabVIEW) based on the Leach SDSU-II hardware. Later, the NOAO instrument group was developing a new controller and software system to be called MONSOON. Naturally SOAR proposed ArcVIEW as the software. The review of this went well until a very senior astronomer/developer came into the picture. He immediately began shooting down LabVIEW, making no attempt to hide the fact that he was prejudice against it's use simply because he wasn't an expert, not about any real shortcomings of LabVIEW, other than that it is "expensive and proprietary" and therefore should be disallowed in favor of GNU C tools, TclTk, etc. This was hogwash, as the same man promoted use of SolidWorks ("expensive and proprietary") to design the optical hardware rather than open source CAD tools/methods. His opinion finally carried the day and MONSOON was developed with text.<br /><br />- Lastly, LabVIEW often gets a bad rap because people try to do things with it that are way way above their skill level. They see that you can do things quickly in it that they wouldn't even consider attempting in a text/OOP lanaguage. They then charge ahead without doing upfront design. They don't apply proper software engineering discipline and practices on non trivial projects and when they end up creating spaghetti even faster than their text programming colleagues do and the project fails, then LabVIEW gets the blame. "Texties" then point to this as ammo to shoot down LabVIEW for consideration in other, more generalized, non data acq projects.<br /><br />- However, with LEGO MindStorms, FIRST Robotics and other educational outreaches teaching this generation of students the benefits data-flow programming, I think it is just a matter of a few more years and you will see a large upswing of LabVIEW use outside of it's current niche.Michael Ashehttp://www.imaginatics.netnoreply@blogger.com