I worked with the LabVIEW team for past 7 years.  During that time, we tried a lot, learned a lot, and continued to build out the platform in many directions.  Somewhere along the way, we realized that the “add-on” modules like Real-Time and FPGA were becoming core to the product, and we could no longer treat them as add-ons.  We got a lot more serious about release cadence and alignment of all the moving parts to the platform.  We kicked off a stronger focus on partners and add-on development.  And we’ve driven a stronger focus on upgrading, compatiblity, and performance.  I think you’ll like a lot of what’s coming in the near future with LabVIEW.

Many of you have shared with me your appreciation for us trying to be more open with our communication.  I think the voice of the customer is being heard loud and clear today  – whether its through formal tools like the Idea Exchange on ni.com, or through more informal channels.   We’ve also started building a team of Field Architects to evangelize best practices and common approaches to application development, and I think that group is on the verge of starting a blog to spread the knowledge.  I’m looking forward to that effort continuing to develop.  You should see great things out of them.  I’ll be sure to post a link as soon as something gets published.

Earlier this week, I snuck into the back of the room during an introductory hands-on seminar that we were conducting at a university.  As I was sitting there watching the most basic concepts of LabVIEW and graphical programming being explained, and saw the students start to grasp the language, it struck me how innovative and cool the basic concept of LabVIEW is, and how even today – 25 years later- it still captures the imagination of scientists and engineers.   Working so closely on all of the big, important, and complicated challenges of LabVIEW for so long made it a little too easy to lose site of the basic value and innovation that’s still core to the product.  We’ll continue to drive LabVIEW into new applications and new technologies, but we’ll never lose site of that core value and innovation of graphical programming.   Perhaps everyone at NI should be required to teach a hands-on seminar at least once each year to make sure we always see the wonder of LabVIEW with our own eyes again.

Looking forward, if there is one software “product” that is as complex, important, and used as much as LabVIEW by our customers, its probably ni.com.  Feel free to drop me a note with any thoughts on how you use our Web site, what you like about it, and how it can be improved.  I’m looking forward to the day that I can bring this blog back to life as the “Inside ni.com” blog – but for now, I’m starting with an internal blog to communicate about our roadmaps and vision.  Like LabVIEW, everyone at NI has ideas and suggestions for the Web site – so I’ll be spending a lot of time aligning internally in the near term.

Specificaly on upgrading, what are we doing?  The first thing we are doing is getting our hands dirty – we are reaching out to customers to get involved in major upgrades so we can walk through the process ourselves.  We’re doing this in a couple of ways:

 1.       Upgrade Assistance detailing the process and examples of the results. 

We have had tremendous success providing upgrade assistance to several large accounts. Upgrade assistance consists of a LabVIEW Product Support Engineer (PSE) helping a user go through the process of upgrading their application to the latest version of LabVIEW. The key word here is “helping”. This is not intended to be a service provided by NI whereby we take your code and magically turn it into working code in the latest version. The PSE works with the user to walk them through the upgrade process, and expedites the resolution of any issues that are discovered. The process has typically taken two weeks elapsed time, start to finish. You get the benefit of learning how to approach an upgrade effectively and a direct contact within LabVIEW R&D to explore and remedy any problems. We get the experience of learning typical issues that LabVIEW users run into when upgrading, and each experience helps to shape our recommended upgrade process.
For a few of these engagements, we published case studies – one of them is 3,000 VIs and the other is 14,000 VIs. 

2.       Adding Real-World LabVIEW Code to Our Test Suite

We have recently instituted a process for adding real-world LabVIEW code to our automated test suite that runs on the daily builds of LabVIEW during our development process. Ideally, we are typically looking for code that meets a few criteria:

1. Large (~1000 VIs or more)
2. Can be separated from hardware
3. Breadth of features (.NET, OOP, external code, RT, FPGA)
4. Little to no 3^rd party software components or issues
5. Application at current release (or willing to upgrade to current release)

The process to incorporate code into our test suite requires some effort on the user’s side to assist us with getting it running in our environment. The code needs to either have existing automated tests, or some willingness on the user’s side to build some. Essentially, we need to be able to load, compile, build, and run the application. Running the application needs to produce a yes/no that indicates the application is functioning correctly (coverage can be very little to exhaustive).).

The application will be re-built and run daily in the new version of LabVIEW. Any issue that arises (failure to load a project or VI, broken VI, failure to build or deploy application, etc.) will have a Corrective Action Request (CAR) filed on it. The CAR will immediately be investigated and corrected. A report is provided to the user with changes, if any, that need to be made to the application so that it will run properly in the released version. This provides the user the opportunity to push back on us in case we underestimated the impact or pain of an issue that may not be resolved at release.

We need to establish a long-term relationship with each user that participates in this effort to improve efficiency, mostly to avoid the high cost of initial incorporation of a user application into our test suite.  If interested in participating in this effort, please contact Jeff Phillips (jeffrey.phillips@ni.com

3. Daily builds

You may not have picked this up in the previous post, but with our renewed emphasis over the past few years on quality and performance, we have overhauled a lot of our internal development tools and processes.  We’ve had consutants in from a number of companies including Microsoft to share best practices (I know what you’re thinking – but the Microsoft group that builds Visual Studio is pretty impressive.  To hear them describe the number of test cases, builds, bug fixes, and code branches they manage in their development process is mind-boggling – but that’s another topic on Software Engineering).  One commitment we are making is to have a daily build of the LabVIEW core stack ready for testing as we go through the development process.  By instilling this discipline into the development process, we feel that not only will the development effort and beta versions will become more stable, but the end result of the release will be more stable and more compatible for users upgrading.  This is a huge change in our development philosophy that was driven by our focus on quality based on discussions with our users. 

One of last year’s resolutions was Better Support for LabVIEW Add-ons, which was so important we carried it over from 2009.   So what did NI do to address this in the past 12 months?  Well, we did a lot actually:

1.  LabVIEW R&D released VI Scripting and the Third-party Licensing and Activation Toolkit, two important APIs for developing Add-ons. 
2. NI’s Web team completely redesigned the LabVIEW Tools Network, an online marketplace allows Add-on developers to share eval versions of their software with end-users.
3. NI collaborated closely with LabVIEW architects  at JKI to support a concept they have been brewing for about 10 years: VI Package Manager (VIPM).

For the rest of this post, I’ll go into the specifics on VI Package Manager, for those who may unfamiliar with it.  First of all, it’s a pretty impressive piece of enterprise software that was developed 100% with LabVIEW. The professional versions offer clever solutions for LabVIEW developers to handle large team-based development, code reuse, and configuration management (important software engineering concepts in LabVIEW). The free version is called VIPM Community Edition, and it’s the reason we count this towards our resolution of Better Support for LabVIEW Add-ons.  VIPM Community Edition makes building LabVIEW Add-on much easier for developers, as well as installing an Add-on much easier for LabVIEW users.  

Here’s how it works: 

You can download VIPM Community Edition for free, which allows you to build and distribute your own Add-ons.  A VI Package is a single file that contains your add-on. Think of it as a “smart zip file” with your VIs, palettes, classes, and more, that VIPM can install automatically. This makes sharing LabVIEW code a trivial task. What else can VIPM do?

• Install a package into LabVIEW seamlessly, so you don’t need to know where to put individual files.
• Handle multiple LabVIEW and OS versions with the same package, so there’s no need to rebuild.
• Automatically compile your G code into the version of LabVIEW you are installing the package into.
• Notify you when a package contains dependencies, give you the option to install them as well.
• Direct you to a package’s Examples and Help after installation.
• Provide a powerful interface for package building (shown below, new for VIPM 2010):

 Who’s using VIPM

VIPM is used heavily by the LabVIEW developers on the ni.com community and LAVA, and is also used by internal groups at NI such as the Systems Engineering department.  To give you a relative comparison, we pulled some FTP download numbers to see at how many new users are downloading VIPM. We compared VIPM Community Edition vs. other drivers, modules, and toolkits from NI.   VIPM was actually downloaded more than any other driver, module, or toolkit, with 28% more downloads than the next highest download, GPIB 488.2. 

 “Grain of Salt” acknowledgment:  NI application software such as LabVIEW, Electronics Workbench Multisim, etc. were not included in the comparison (only modules, toolkits, and driver software were considered).  Also, many customers install NI application and driver software from DVDs which do not show up in these numbers.

What’s next for VI Package Manager

How will VIPM evolve to support Add-ons in the future?  I’m sure the developers at JKI and the LabVIEW Partner team at NI would love to hear your feedback.  For example, on the Idea Exchange is a post reflecting some feedback we’ve heard for managing IDNET instrument drivers with VIPM.  Feel free to share your ideas on the Idea Exchange, or email labviewpartnerprogram@ni.com.

I’ll try to hit the rest of our 2010 resolutions in the next few weeks. 

Thomke’s book, on the other, hits right in the center of our world by focusing on how new tools can enable engineers to innovate faster and generate better products with a shorter time to market.  He studies the automotive industry – one that has a huge investment in tools with a lot of history.  The general hypothesis is that with better design and simulation tools – higher fidelity models, faster simulation, etc – automotive companies can iterate faster and reduce the number of prototypes they have to actually build and test.  While this sounds obvious, in practice it didn’t actually prove itself out.  He looks at hundreds of new car designs, comparing the Japanese automakers with the Big 3 in Detroit.   It turns out that better tools alone will not yield better results – new tools have to be accompanied with new approaches to the problem to result in real improvement.  In fact, in some areas, the new tools led to more time and money spent, as evidenced by this quote from his work:

“Many of our engineers were not ready to accept the results from simulated tests [that is, those using the new CAE tools] because they aren’t [considered] real. When senior management decided to invest in new information technologies, simulation software and specialists, they anticipated substantial savings. But the more we simulated, the more physical prototypes were built to verify that simulation was accurate. No one was going to make a commitment and decision based on a computer model only. Because of simulation, we ended up spending more money on prototype testing than before.”  [source]

There are many themes here that are both interesting and directly relevant to our space in measurement and automation:

• New tools can’t be used simply as substitutes without changing how you approach the problem.  New tools should also drive process change.
• Simulation and test need to fit together in a complementary way – one will never eliminate the need for the other.
• Change is not always for the better, and technology for technology sake may not help your business.

I suppose you might think we are concerned about simulation and its impact on testing.  On the contrary, LabVIEW and our virtual instrumentation strategy is not just a new technology, but really a whole new way of thinking about test and measurement.  The fact that we approach the measurement task from a software perspective, means we have a much better opportunity to tie simulation tools more closely with our test platform and save real time and money for our customers.  And finally, with our RIO-based prototyping approach, we see even more opportunity for the simulation world folding in nicely with our platform.

Even though Thomke’s book is not particularly new (published in 2003), its a particularly interesting read about how tools- particularly simulation and test – have real impact on product development.

Here’s the long story as to why (in case you have an inquiring mind):

We recently rolled out a new internal system for managing our software packaging and shipping that is much more flexible for us.  By flexible, I mean the new system will take us from having over 1100 part numbers that we stock, forecast, and manage, to around 400 part numbers.  As you can imagine, this will simplify our manufacturing and stocking issues significantly.  The new system also makes it much easier for us to manage customer services and subscription contracts – meaning you can add other products to your contracts, align renewal dates, and add multiple year support to your purchases. 

We went live with this new system in late February – right when we normally are turning over our inventory for service packs and shipping them out to our customers.  LabVIEW 2009.1 released to manufacturing in late January.  Rather than scrap all 1100 part numbers in stock, re-release them with 2009.1 and put them back into stock, only to then revise the system – meaning all 1100 part numbers get scrapped again – and re-release 400 new kits…. we chose to save some trees and minimize our risk by making sure the new system was up and running before we moved over.   March is off-limits for any significant changes to our systems because its a big month for our business and as a public copmany we don’t ever put that in jeopardy. 

Rather than hold the software until April for release, we made the Service Pack available for download – so customers who really needed it could go download it immediately   as soon as it was ready.  Once we rolled over to the new system (April) we would then ship everyone their physical DVD media.  (Of course, a volcano got in the way as well, which made early/mid April turn into late April).  A number of our sales people were concerned that their customers may not be able to download the software due to bandwidth limitations or policies about internet access at specific locations.  Although we are investing in making the download process better for our customers, we are also continuing to ship feature releases and service packs to our customers on service.  We hope to make that configurable in the future.  For now, enjoy LabVIEW 2009.1.

Another thing that’s cool about this program, is that we’ve recently introduced different levels of “Compatibility” to differentiate between the maturation of different products.  For example, if you have a new product, you can start out at the Standard level to begin with and simply demonstrate to us that you’ve met the LabVIEW Style guidelines.  (We aim to keep it pretty lightweight to get started)  Over time, to achieve the highest level (Gold), we put your product through the ringer with integration and usability testing, and also require the product is field proven and was coded by a Certified LabVIEW Developer (CLD) or Certified LabVIEW Architect (CLA).  This means a great deal to other LabVIEW developers, who end up using your product in their applications, because the Compatible with LabVIEW logo means it’s been reviewed or tested by NI and meets LabVIEW best practices.   

By the way, there’s a lot of marketing benefits that accompany this program, such as using the program logo on your own website and product brochures, a product listing on ni.com, newsletter features, and booth signage at NIWeek.  And while we’re not ready to let the cat out of the bag just yet, we’ll have a lot more exciting news about our re-launch of the LabVIEW Tools Network at a late date, which is tightly coupled with the Compatible with LabVIEW program. 

Here’s how to get involved with testing your product with LabVIEW 2010:

1. The first step is to join the LabVIEW 2010 beta if you’re not already on it:  ni.com/beta.   We’re happy to help with putting together a testing plan for your product if you are looking for ideas.
2. Next, go to the Add-on Dev Center to apply for the Compatible with LabVIEW program ni.com/addondevcenter.  Be sure to apply by May 28^th to meet the NIWeek prioritized deadline.  (otherwise, we accept applications year round)

Let us know what you think about the changes to the program, and keep the applications coming!

In fact, she has even created a chart that explains the adoption process of software and the psychological impact on the users that any Harvard MBA would be proud of called “the kick ass curve” shown below:

I also like the pop quiz that she opened her presentation with – as a software developer, do you want your users to think:

• Your company kicks ass

or

• Your product kicks ass

Turns out, its a trick question – watch the video to see the right answer… and I hope all of you feel like you kick ass when you are using LabVIEW.

There are a few additional aspects to capturing user input that we are going to try to develop this year (in no particular order, with no guarantees – sometimes a good idea turns out to be stupid or impossible after y0u look into more…)

1. Capture usage statistics – A lot of the decisions we make could benefit from more user statistics.  For example, if we are considering deprecating an API or support for a particular operating system, it would be nice if we had a way to know exactly how many users are currently using that API or OS flavor.   We can get some information through newer tools like Activation – we are trying to intrpret activation data right now to get a better feel for new version uptake statistics for example. 

Before we would actually do anything in the area of user tracking, let me first reassure you.  Any effort to track what users are doing would be opt-in first and foremost (similar to how Google tracks your search activity to understand how they can make Google better).  And, there is a huge spectrum of possibilities that we are currently thinking about – from doing a better job of tracking your name and email address when you register so we can guarantee technical support access when you call in, to possibly instrumenting the beta versions so we can see how you use the product.  Today, we look at web traffic to try to understand trends and changing interests or challenges from our user base, but we can probably do more.  These are all just ideas under discussion right now – I hope to have a more concrete plan later this year that we can vet out with users before we start moving forward.

Another topic in the “user input” area is more about how we engage on a face-to-face level with big customers.   Last year, we made a concerted effort to document and present product roadmaps for LabVIEW at NIWeek, customer advisory boards, and with key customers.  We are moving in a lot of directions with LabVIEW, and developing some standard roadmap presentations is one way to communicate our plans to key customers.  However, we have so many ideas and investment areas for LabVIEW, a roadmap presentation can degrade into a one-way conversation if you are not careful.   It works both ways too – anytime a sales person tells me one of their customers “wants to have a LV roadmap presentation,” I respond with a lot more questions.  I can waste a lot of time presenting roadmaps that are completely irrelevant to the customer.  Sometimes our sales guys and our customers both don’t realize that we have multiple roadmaps and directions we are going with LabVIEW.

 This year, we’d like to evolve our roadmap presentations into a two-way discussion where we are truly exchanging technical and business challenges with our customers and mapping future investments into these gaps.  To start with, we will be reaching out to some of our biggest customers who are on volume licenses to establish a regular technology exchange engagement.  We can share what we are working on and where we are trying to go in exchange for getting more insite into the real challenges that the customer is facing.  This may sound obvious, but most conversations about LabVIEW with experienced users invariably come back to discussions about specific features or problems and don’t look further out at the new challenges that are customers are facing.  I am not exactly sure how to share what we learn in these exchanges as they will be confidential, but some general trends and strategies will emerge.

We’re mocking up some ideas right now and hope to get it formally presented and approved as a LV 2011 feature sometime later this Spring.  Perhaps we can share the specification documents on Idea Exchange to see what the user community thinks.

We’ve started a bunch of internal experiments to get back to basics – like asking senior executives to req out a copy of LabVIEW and some hardware and perform a basic measurement.  It’s already yielding some great insite into the out-of-the-box experience and ideas for improvement.  We are also working on a more unified approach to introducing LabVIEW and our hardware to a new user.  With a simple assumption that a developer using LabVIEW will have access to the internet, we can start to feed getting started instructions to users through Web pages and then track what users are actually using and how well this new approach is helping them.  We’ve been studying a lot of other tools that either target engineers (mechanical CAD software like AutoCad or Solidworks) or are similar in their technical capabilities and breadth (media design software like Adobe for Web/photo/video editing and production). 

We should have our first pilots available this Spring so you can see how we are doing (although if you are reading this, chances are good that you are NOT a new user…)