Lowering engineering anxiety is a key reason to embrace reuse. That said, the quality of the reuse component must be significantly high enough to eclipse the engineer’s natural want of doing it themselves. I’ve seen situations where an engineer is burned by one reuse component and arbitrarily decides to abandon all reuse components and code everything from scratch themselves. This is, of course, incredibly immature, but also a little understandable. What those people need to do is recognize that not all code is perfect (including their own), and that reuse is an iterative process. Plenty of effort is usually put into bringing new components into a reuse ecosystem, but an equal (if not more) amount of energy is needed to maintain and upgrade existing components (there’s less glory there, but it’s as, if not, more, important). That’s why organizations that truly want to succeed through reuse need to have a process in place to avoid these pitfalls. Otherwise the reuse effort is (after a flurry of initial excitement and effort by a champion or two) is doomed to fail. Another key factor is that the process needs to involve everyone – all of the users of the reuse components, not just a champion or two.

I could go on, but I fear that I’m starting to evangelize If you truly want to hear me wax philosophically about reuse, all you need to do is find me…

I totally agree – that’s why I said this: http://jkisoft.com/vipm/customer-quotes/

Jim Kring also wrote: “(library participants to easily know what to expect) One possibility is to have two separate packages for each package category: one that is “certified” (meets organizational quality requirements) and another that is “uncertified” (does not meet certain quality requirements).”

We (kind-of) do that with a candidate and accepted deliniation. Reuse candidates are specified so by them being placed into a designated area by the submitter – all engineers are welcome to use code in the candidate area, but at an unknown level of risk. Once the candidate is accepted to the reuse review process, it is copied to another area where it is worked on to bring it up to QA requirements, changed to be more.less generic, etc. Once it’s through that process, it is released (consequently as a VIPM package in a controlled common area).

Then Jim Kring wrote: “Can VIPM play an important role in facilitating the sharing and evolution of prototype reuse code in addition to mature reuse code that has gone under extensive testing, review, and other quality control processes?”

It’s certainly worth discussion, but I’m not sure how. Components/Modules/Architectures that are yet to be certified are often in a state of heavy flux, and I don’t see how VIPM’s features (in their current form) can be applied to that. That said, let’s look to the future…

One more thought… Regarding your comment: “Trust – a lot of my job is about lowering engineering anxiety, and this is a big area of it.”. This is a huge aspect of software engineering. The less that software engineers have to worry, the more that they can spend their energy creatively solving problems.

-Jim

Wow! That’s a long comment — looks like you need your own blog

One reuse concept worth contemplating is that, in addition to highly-reliable and well designed code, there needs to be an environment where people can easily work on and share reusable nuggets of code. If we make it easy for reusable nuggets to be shared, then we’re lowering the activation energy of software reuse and promoting cross-pollination of ideas. Just as people require high-quality code that they can count on, they also need a place where they can quickly share things that are at the concept/prototype stage.

I believe that VIPM can play a critical role in facilitating software reuse at this early stage as well. And, because VIPM is highly modular and offers configuration management capabilities, users who decide to use concept/prototype stage code in their projects do not run the risk of having changes to prototype code break their project unless they upgrade the packages that contain them.

What this sort of process requires is a way for reuse library participants to easily know what to expect from a given reuse artifact (what is it’s development status, quality level, etc.).

One possibility is to have two separate packages for each package category: one that is “certified” (meets organizational quality requirements) and another that is “uncertified” (does not meet certain quality requirements).

Another possibility is to segregate the “uncertified” code into some subfolder of the package. You could make it clear that a VI is uncertified by coloring its icon and putting notices on the Front Panel and VI description.

What are your thoughts about this? Can VIPM play an important role in facilitating the sharing and evolution of prototype reuse code in addition to mature reuse code that has gone under extensive testing, review, and other quality control processes?

Thanks,

-Jim

We package in a way that reflects the struture of the default LabVIEW palettes (eg: we have a Programming.Numeric package, a Programming.Array package, a Programming.Dialog & User Interface package, etc), along with package icons that are the same as their counterparts in the standard palettes (with a little VIE glyph in the corner). We do this for a couple of reasons: it’s more intuative for the user, and we hope to one day be able to put our palettes directly into the exisiting palettles. Sure, occasionally we have a need to create a package that doesn’t fit within the default model (eg: we have an Addons.VIPM palette for all our VIPM pre- and post-build hook VIs), but they’re decided on a case-by-case basis.

I think one of the reasons that we’re successful wit reuse is that we have a documented process that defines how to buuild a package the “VIE Way”, which includes where to put items – this menas that we don’t need a select group of engineers to keep control of the internal reuse package repository (we do have a repo librarian, but their role is strictly QA). Everyone is encouraged to be a different part of the process for a subimission – this limits the senior-engineer-only elitism that can occur, which really devalues reuse (as Bob suggested).

I totally agree with Jim’s four key factors:

Accessibility – that’s what VIPM is for. We have tried several methods to acheive this previously (including in-house tools), but VIPM is certainly the best tool hor accessibility IMHO.
Familiarity – training, training, training. We have a TSIG (Test Software and Integration Group) meeting every week, and one of the parts of that meeting is a short session on items in our reuse library (as well as items available through OpenG). Engineers won’t use something if they either don’t know about it or don’t know how it will benefit them.
Quality – how easy wil it be to implement in my code? Would it be easier to just make my own rather than try to understand what’s going on here?
Trust – a lot of my job is about lowering engineering anxiety, and this is a big area of it. The question here should not be “will the reuse code be as good as if I’d written it?” Instead, it should be “does the functionality of the reuse code meet my requirements (or will with a lottle wrapping/brokering)?”

I wasn’t planning on writing so much in this comment

Thanks for the feedback.

I agree with you about organizing reusable VIs into subfolders. I had to try not to get ahead of myself and keep the article simple — there’s really a lot to cover when we’re dealing with software reuse.

In the VI Package Guide on the JKI Software website, we have a page called “Packaging your Reuse Libraries” that has some tips on how to organize a reuse library. The first step is to organize your reusable VIs into categories that will become individual packages.

For beginners, we try to have them just build a single package as a starting point — they can always split the package up into categorized packages, later.

I’m happy to hear that you’re going to be spending some time learning about VIPM! I’m looking forward to chatting with you about your experiences and feedback.

Thanks,

-Jim