Guest Post from LabVIEW R&D Director David Fuller – Stability vs Annual Releases, chapter 2

David Fuller is one of my counterparts in the LabVIEW R&D team who gladly accepted my invitation to respond to this discussion from the R&D perspective.  David started his career at NI as an intern in our instrument driver development team about 16 years ago – so he started from day one eating our own dog food.  Today, he is one of the two key R&D Directors responsible for LabVIEW development.  As he is a good friend of mine, I will share his post unchanged as he sent it to me, complete with playful jabs (deep down, I know he wants to move to Marketing some day):

Thanks. While I am not the Wolf to Pasquaratte’s Vincent, I can weigh in on the R&D view of quality, the yearly release cycle, and the degree of openness in R&D and marketing for releases, bug fixes and so on. I do happen to work for Bellin, but I won’t suck up to him like JP does to Zogas.

It is no big surprise to anyone that we now release a major version of LabVIEW at NI-Week each year. It just makes business sense for us. From the R&D perspective, we have been pleasantly surprised with the positive side-effects on our product development. First and foremost, the yearly release cycle forces us to be more disciplined while adding new features to LabVIEW. In years past, we had the notion of the “no turning back feature.” A no turning back feature is the kind where development changes are so pervasive that we have to touch most of the code base and its core architectures. Once we started, there was no turning back and the release became gated by the feature. The teams responsible for the feature would then go on a classic death march and work like heroes to get the thing done. The psychology of the heroic effort, the long hours, and the sense of shared purpose all have some positive characteristics, but the negatives of burned out minds, cut corners, and reduced quality don’t make for a sustainable way to develop LabVIEW. Now, because our release date is fixed, all features must either clearly fit the development window, be staged in, or turned off easily and safely. For example, DFIR or data flow intermediate representation, is one of our more difficult efforts aimed at consolidating our compiler architecture. We have actively developed DFIR for almost two years and parts of it were present, but inactive, in LabVIEW 8.5 and 8.6. We believe the architectural changes will make this year’s LabVIEW release, but even so, we are able to disable it safely if we need to. Its a clear example where we are trading off better quality versus our rate of innovation. If I think back to the LabVIEW 8.0 days and how we were operating then, I think we would have jammed it into LabVIEW and released it before it was ready for prime time. I do think we have started striking a better balance between getting in new interesting and useful features and keeping the subjective quality bar high.

Aside from our improved feature development discipline, the yearly release has improved coordination between R&D groups and between R&D and marketing. (Perhaps its freed up time so that the leaders in marketing have time for blogs, but I digress.) The NI-Week release creates a near company wide set of testing milestones. While it may seem obvious, when we release different hardware and software at different times throughout the year, the testing is localized to the group doing the releasing and there is a greater likelihood that some important interaction won’t get the right test coverage. Creating R&D-wide synchronization points, ensures a lot more test coverage for a lot more product combinations. Once we went through the platform-wide release, we realized it would make sense to ship all of the software tested at the milestone and this led to the SingleDVD project (that and a painful 120 slide show from marketing showing the customer installation experience when using cRIO with LV RT, FPGA.) Ironically, when we created the feature, we called it SingleDVD, but LabVIEW, the modules, the toolkits, and the drivers now take up at least three DVDs and counting.

By coordinating nearly of all NI’s R&D around NI week, you get a higher quality product because of our improved feature development discipline and through the concentrated and coordinated testing of the platform. So long as we remain disciplined enough to not force features into the release, I think we are now striking the right balance between innovation and quality.

Finally, Per Milan’s response, I really like the idea of targeted feedback mechanisms and better bug reporting within the product. As we are working on some of our features related to connecting desktop LabVIEW to NI’s business systems, we will look to see what we can do on that front.

Regards

-David Fuller

Director of LabVIEW Platform