# 5
- You (and your team) aren't using the reuse library.
You
had big plans for your reusable VIs. You organized them.
You
had meetings to review them. You assigned someone the job
to clean
them up
and create a
great big library for everyone to share. But, that
was
years ago and, after the initial burst of effort and excitement,
progress and interest tapered
off. You realized that reusable VIs were either too much
trouble to find or too much work to maintain. You're not
really
sure what went wrong, but something did go wrong, because your
reusable VIs (and all the effort you've invested in them) aren't
being reused.
# 4 - You haven't added new VIs to your reuse library
in
years.
Something killed the fun and/or productivity gain you
thought would be realized when you started your reuse library.
You're not really sure what it is, but you know that it's
just
too much work to reuse VIs. Sure, you're reusing a VI here
and
there, but your
grand reuse library isn't really growing -- it's just too
much
work add new VIs to it.
#3 - You're missing VIs when
you open your project and palettes.
You write a great reusable
VI for project A, so you copy it over to project B. Then, you
find and fix a bug in a reusable VI while working on B, so you copy
the fixed VI over to project A. When you try to open your
project after copying your reusable VIs, you're missing some
important subVIs. Or, maybe they are missing
from your LabVIEW palettes after you spent hours getting the
palettes just the way you like them. You spend even
more
hours trying to find the missing VIs and put all the pieces back
together. In the time you spend, you might as well have just
rewritten the VIs from scratch.
#2 - You have
multiple copies of your reusable VIs in several projects, but they're
all slightly different.
When projects are started you always
grab the latest and greatest version of your reuse library.
Why
wouldn't you? Then, as you work on your project, you find and
fix a few bugs, and add a few useful VI inputs and features.
Like
most people you tend to work on one or two main projects at a time
and do occasional maintenance on a handful of others. But,
when
you're working on a project you're more focused on getting the job
done, than you are in making sure that your "main reuse library"
gets updated (or that the copies of it in various projects are kept
in sync). As a result, each project has a slightly different
copy of your reuse library. In fact, you might have even
fixed
the same bug multiple times in different projects. And,
you're
not really sure which projects have the fix and which ones still have
the bug.
And, the #1 sign you're not in control of your reusable VIs...
1) You've rewritten the same VI
over a dozen times!!!
You have had ambitions to create a
reusable VI library, but you never really got around to it (or,
you've tried and have not gotten very far). It's way easier
to
just
rewrite a VI than to find the one that you
already
wrote, because you have no idea where that other one is. But,
you're rewritten that same VI at least a dozen times and it's driving
you crazy! You've just about had it.
You wonder,
"I'm
an engineer, so why do I keep reinventing the same wheel?"
So
what now? Should you give up on the idea of reusable VIs?
Of
course not -- don't give up. One great solution is VI
Package Manager, as it
allows you to easily manage your reusable VIs accross multiple projects
and computers. Stay tuned for my follow-up
article The
5 steps to take control of your reusable VI library where
I'll
tell you everything you need to know to regain control.
“The 5 steps to take control of your reusable VI library”: Step 1: start using it. Step 2: Start adding to it. Step 3: Find your missing VIs. Step 4: …
Aristos: I see that you’re paying me back for my earlier jabs
And, yes, the steps you’ve stated are easy if you’ve got one great big monolithic reuse library that ships every 18 months. However, most LabVIEW users work on several (if not tens or possibly even hundreds of) projects, released frequently, where they want to reuse VIs and collaborate on those VIs with others in almost real time.
how much do I agree..
I can tell that story from the start to the end. Now.. how hard is it, when you are at that point to say “ok, if we keep on this way we’re going to hit the wall,, let’s work differently”
open question looking forward to feedback.. who ever went down this process of re-organizing re-use library from monolithic to modular ?
Antoine,
Someday soon, I will share my story (probably as one or more blog posts) about my own work in transitioning reuse libraries from monolithic to modular, both at OpenG and JKI. The pain that I’ve felt along the way and the lessons I’ve learned have (as you might guess) shaped what VI Package Manager is today. I am truly passionate about software reuse and VIPM as the “ultimate tool” that I (and others at JKI) have always wanted for ourselves
I am certainly interested to hear other people’s stories too. I’m imagining, though, that few have tried to (or have gotten very far in) re-organizing a re-use library from monolithic to modular up to now, as there are many tedious steps that need to be automated with proper software tools.
Thanks,
Antoine: we did at V I Engineering, and have never looked back. The VIPM was a very important part of that step. We are now able to manage our reuse throughout our team. It certainly wasn’t easy, but with some good planning and the right support, then nothing can hold you back
Crelf:
What efforts do you take to make sure all you programmers are up-to-date?
Ton
Ton: we have an internal wiki and forum that is updated with package changes, and our engineers have either an RSS feed to those or receive automatic email notifications when they are updated. The team also meets weekly where we dedicate 10 mins for a team members to show their recent additions (as well as their favorite OpenG components).
Oh - and there’s a big brass ship’s bell in our HQ office that reuse submission sponsors peel when a package is released or updated
Ton: I see your question really needing to be separated into two important questions:
1) How do teams ensure that all developers are using the same version of packages for a given project?
2) How do we inform team members that new versions of packages exist and what is different (hopefully better) about the new versions?
For solving #1, we recommend that (for every project) users create a VI Package Configuration file and putting it in the project folder (and keep it under source code control). The VIPC file can optionally include the actual package file so that all project developers have a copy of the package to install. You’ll note that this is a way of actually sharing packages with other developers. By applying the package configuration, you are adding the packages that are saved in the VIPC to VIPM’s package list.
For solving #2, you should probably rely on some form of publish and subscribe system. For example, subscribe to email or RSS notifications of new packages. This can be done with wiki’s (as crelf described), mailing lists, etc. Now, we would certainly love to have some way to do this in VIPM and that might be something that we’re working on
If you have ideas or questions about this, we encourage you to discuss them on the JKI Software Forums — we’re always listening and happy to hear your feedback.
Wow.. I’ve lived all 5 scenarios… :o(
Plus I have the VI Package Manager… I’ve got to find the time and start using it..
RayR
If you saw the way I do reusable VIs, you’d drop your coffee cup. Bwah ha ha ha!
Darryl: It’s not nice to just tease us
Can you share any of your ideas on methodologies for reusing VIs? Personally, I’d love to hear them.
Alas, the development work was done on a confidential contract for a particular client. However after completing the job, I initiated a 2nd-gen. effort from scratch for myself. After the 2nd gen stuff is up and running, I may cruise by and do a demo for you one of these days when I’m in SF. The timeframe is maybe a month or two.
The work I do is customized for Analog Semi bench-test systems so it might not be appropriate for the industrial control guys but the reusability solution is unprecedented. The 2nd-gen version is going to be sweet.