LabVIEW Stability vs Annual Releases

In a recent info-lv post, a user was commented on the stability of different versions of LabVIEW and added this:

I hope this reply is read by the person at NI who makes the tradeoff between marketing and the necessity to create a “new” version of LV yearly vs. stability & reliability. I have great respect for the programmers at NI and have full confidence that they’re able to produce a highly reliable product; but not with a looming marketing deadline and huge feature list to implement yearly.

Obviously yes, your hopes that someone at NI reads your post have in fact come true.  “Stability” is a hard thing to measure, but I felt like the info-lv post with users weighing in on their impressions of stability of various versions of LabVIEW were right on the money with how we would respond.  However, I have some comments that I will share about the benefit of a more regular release schedule.  In addition to my comments, I have also invited the LabVIEW R&D guys to weigh in on this too with their opinion – so stay tuned for an upcoming guest blog post.  (I will try to keep these comments brief and leave room for R&D and our users to comment):

1.  An annual release improves stability –  In the past, we’ve gotten locked into huge development efforts with long cycles – like LabVIEW 8.0 – which has resulted in some stability challenges.  The fact is, LabVIEW 8.0 was such a huge release with so many features – many of which involved some very deep and fundamental areas of the product - that we took a hit.  8.0 was a long development cycle that was very painful to get out (I’m sure you’ve all been on “deathmarch” projects as well). With a team as big and complex with as many dependencies as we have with LabVIEW, it’s almost impossible to operate with open-ended schedules.  What tends to happen when you do that is that some particularly important feature becomes the critical path, and while we are finishing that feature, everyone else naturally starts to squeeze in new things.  As new things get added, we have to go back and redo some testing and validation.  A vicious cycle ensues.  The longer testing cycle means new things can get added… etc.  I think this is one of the things that impacted our 8.0 quality.  Not to mention the fact that when there are THAT many new features added to the product, its very difficult for our users (and our marketing department) to fully understand and take advantage of them.
2. Annual releases are critical for alignment across all of our internal (and external) constituents.  With an annual release, we now have moved to a much more predictable schedule.   Admittedly, we’ve added a little overhead in testing and releasing every year.  But we removed a lot of the unknowns that we struggled with in the past.  

   We no longer have these exchanges: 
   Marketing:  “How’s the new version coming?”
   R&D: “Great”
   Marketing: “Is it going to be ready by NIWeek?  We need to prime the pump before then?”
   R&D: “I’ll let you know when its ready?”
   Marketing: “hmmm…  We better come up with a backup plan for the keynote”

   All joking aside, we now have a standard schedule and the train leaves the station every year at about the same time.  The developers know that key features need to get slotted into a release- if they miss the train, they know the next one is coming around a year later.   When we work on larger, multiyear development efforts, we do need to manage the rollout in a more sophisticated way – at times, we test and ship code that is a foundational element for something that users won’t take advantage of until the following release – we just have to roll it out piecemeal that way.   

3. We need a regular release schedule to accomodate the diversity of the LabVIEW platform components.  Different parts of LabVIEW have to move at different speeds.  For LabVIEW users who are using GPIB instruments only, they probably can wait two or three years for new features to the environment.  For less mature parts of LabVIEW, such as LabVIEW Real-Time or FPGA, we have to move pretty quick to continue closing the gaps we have there in functionality, usability, and hardware support.  We are making much bigger strides there on an annual basis.
4. Customers prefer knowing our release schedule - We haven’t explicitly communicated to our customers our strategy shift to annual releases – we wanted to get through a few of them to see how it went before proclaiming success.  However, I have found that many of our customers appreciate knowing the basic plan (new features followed by maintenance releases) on our side to help them manage their own development strategy. A completely different topic is how and when customers upgrade their LabVIEW-built applications.  The fact is that there are many factors that go into this decision.  Sometimes, there are key features they want to take advantage of, but in most cases, the reason customers upgrade is driven by risk, timing, and hardware issues on their side.  This is a known area that we are focusing some resources to help, but I think smaller, more regular releases will ultimately help smooth this process – but that is a different blog post. 

In all of this, there are small set of requirements that we work very hard to maintain and improve upon for every release:

• Every version of LabVIEW needs to be stable
• Upgrading from one version to another should be a smooth process – we should not break your code if at all possible
• Everything should work together when you move to a new version – when you upgrade, you need validated versions of all the toolkits and modules as well (the new DVD in 8.6 goes a long way in simplifying that issue).