You may have already noticed that my blogging activity has slowed recently. Late last year I moved into a new role – Vice President of eBusiness – here at NI. I’ll be responsible for ni.com and many of the internal systems and processes for publishing, e-commerce, user community, and communicating with our end-users. Obviously, now that I am no longer in the middle of day-to-day LabVIEW activity and decisions, I don’t have as much to say in my “Inside LabVIEW” blog.

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.

This is another holdover from 2009. I’ve seen the look of terror in user’s eyes when the prospect of upgrading their huge, mission-critical applications comes up. This is one of the more challenging areas we face because of the sheer number of components, drivers, hardware, and third-party libraries that may be involved. Because of this, we’ve shifted our focus in general with the LabVIEW team to be less about new features and more about locking down the features we have to make them more solid, and more compatible between versions. Quality, performance, and compatibility are a primary focus in this timeframe.

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:

Large (~1000 VIs or more)

Can be separated from hardware

Breadth of features (.NET, OOP, external code, RT, FPGA)

Little to no 3rd party software components or issues

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.

It’s been awhile since I’ve blogged – that’s due to lots of changes over the past few months (more on that later). I’ve used these LabVIEW New Year’s Resolutions as a way to keep us honest and focused – when you publish a set of initiatives that we all agree are important, you can’t run away from them (and you can use them to combat the “idea of the week” which the LabVIEW team is hit with on occasion). So here goes for 2010 reviews…

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:

LabVIEW R&D released VI Scripting and the Third-party Licensing and Activation Toolkit, two important APIs for developing Add-ons.

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.

With NIWeek right around the corner, talk of innovation is in the air. As part of this talk, I’ve been browsing through book entitled “Experimentation Matters” by Stefan H Thomke. Thomke is a Harvard Business School professor who focuses on technology and innovation. The subtitle of his book is “Unlocking the Potential of New Technologies for Innovation”. I know what a lot of you may be thinking – sometimes these HBR articles and books tend to come across as a little to lofty, academic, or perhaps focus more on consumer product areas rather than engineering topics.

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.

We’ve had quite a bit of confusion (at least in our sales force) around our shipping policies and the recent handling of LabVIEW 2009 Service Pack 1. The short answer is – Yes, we are sending media to all LabVIEW and Developer Suite customers active on service. If you have not received yours yet, I have been assured that our shipments should have started hitting your docks last week (we were delayed even more due to the volcano in Iceland).

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.

Just a heads-up for all our Add-on Developers, our LabVIEW partner team is accepting prioritized applications through the end of May, to guarantee that your LabVIEW-based product will be tested with the LabVIEW 2010 beta. Any company that has a LabVIEW add-on product or driver is eligible, it’s free to participate, and upon review of your product we will provide you with technical feedback and ideas on how to improve your add-on.

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:

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.

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 28th 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!

A member of the development team who is passionate about usability and design alerted me to this presentation last week – its a youtube video of Kathy Sierra’s keynote presentation at The Future of Web Apps conference from 2008. Kathy is the creator of javaranch.com and is a former game developer and author of some O’Relly technology books. She speaks a lot about how tools vendors (or in this case Web tools developers) can create passionate users of their development tools. I really like her presentation because she breaks down the challenge of building software that people can use in terms that we all can understand. Your users will either feel like they suck, or they kick ass based on what they can do using the tools you provide them.

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.