You’ve probably created lots of reusable gems in your past projects that just needs to be polished up a bit.  Now is a great time to dig these up, improve them, organize them into a reuse library, and then use VIPM Professional to convert your reuse library into VI Packages.

The truth is, just because your time right now isn’t billable to customer projects, it doesn’t mean that you can’t profit from this “free” time later — if you’re working on reusable code that you can use in future projects, those future projects will get done faster and with higher quality by leveraging your reusable code.

Great companies work hard through slow downs, training for the moment that the starting bell rings, signaling the start of the next round.  Then, they come out strong and ready to scrap.  If you think a slow down at work is a good time to go on vacation, then you’re the one whose going to get knocked out by the competition.

This tool is the direct result of putting some of the best LabVIEW minds together for several years, tasked with the challenge of creating a LabVIEW architectural design pattern that would allow easy coding, readability, and maintenance.  As you might imagine the JKI team has created something truly special that we hope will have a significant impact on LabVIEW users everywhere.

This has been in the works for quite some time and we’re excited that the time has finally come to share this tool with you, now.

Please take this challenge:

1. Download and install the JKI State Machine.
2. Watch this great video tutorial.
3. Take a look at how we refactored the 3-button dialog (VI that ships with LabVIEW) using the JKI State Machine.
4. Tell us what you think.

For example, if you were a miner looking for precious minerals, you would wouldn’t roam the countryside digging random holes in the ground.  Rather, you would work smart — you would try to identify a geographic location with a very high natural concentration of precious minerals (based on a variety of clues).  Guess what?  This is exactly how you should mine for reusable code in your past projects.  But, where do you start looking and what are the clues that will lead you to those reuse gems?

Here’s the secret:

While writing code, when you identify that you are writing a VI that is generic and has the potential to be reused, save it inside a sub-folder of your project folder called “Reusable VIs”.

If you adhere to this strategy, it will be very easy for you to come back later and find your reuse gems.  And, before you know it, you will have what resembles a reuse library.  Best of all, you didn’t even have to get your hands too dirty.

Note: As your reuse library grows (which it will if you use the planning techniques described above), you’ll need to start thinking about how to utilize your reuse library on multiple projects and share these VIs with other developers.  Make sure you don’t get stuck in the pitfalls of a monolithic reuse library caused by copying your reuse library from project to project or by using the same version of your reuse library on each project.  Create a VI Package and install your reuse library in your palettes using VIPM — it’s easy and simple.

I’d love to hear your feedback, so please feel free to leave a comment.  For example:

• Do you have a folder in your project where you put new, reusable VIs?
• Do you think that this is a good idea, or do you have a better strategy?

# 5 – You (and your team) aren’t using the reuse library.

You used to have 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 an initial burst, 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 that was put into 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.

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 not gotten very far). It’s way easier to just rewrite that 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 you keep reinventing the same wheel?”

So what now? Should you give up on the idea of reusable VIs?

Of course, we should not give up.  One great solution is VI Package Manager.  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 slow death of the monolithic reuse library

• As the monolithic library grows large in size, it becomes hard to distribute -- it consumes large amounts of disk space and network bandwidth
• Users must choose a single version of the entire monolithic library for use in their projects -- it's all or nothing 

• Users fork the reuse library -- Users make a copy of the library locally in their project and modify it.  They possibly only copy subsets of the reuse library, breaking the monolith.
• Users stop upgrading to newer versions of the reuse library -- Users forever stick with an out-of-date, stagnant version of the reuse library, even though they might be able to take advantage of improvements made to some parts of the library.  The cost of upgrading, due to the possibility of breaking code is not worth the possible benefits of the new features and fixes.

• Improvements to the library stop, because nobody ever upgrades to newer versions of the library.
• Improvements to the library happen in project forks.  Either these changes never make their way into the main reuse library or are copied between projects adding tremendous uncertainty and ambiguity as to which versions of library components are being used.

Enter the modular reuse library

•  
  • downloads are faster and less project disk space is consumed
  • upgrades can be done on a per-component basis, minimizing the risk of upgrades and the amount of testing required to re-validate code

• there are more software products for library developers to manage -- each has its own life-cycle
• there are more components for users to obtain -- these have to be found and downloaded, and if one component depends other components, these have to be identified and obtained, too 

VIPM 2.0, a modular reuse library development tool for LabVIEW

Monolithic vs. Modular Reuse Libraries

src="http://thinkinging.com/wp-content/uploads/2008/02/el_cap.png" style="padding-top: 10px;" align="right" border="0" hspace="4" vspace="0"> zid="34"> Monolithic wins the short race

• easy to distribute – it might be delivered as a single ZIP file, or a checkout from source code control.
• easy to keep track of which version you have – there is a single version number for the entire reuse library (perhaps a date stamp)
• easy to manage, since there are no external dependencies – every VI that you need is kept within the reuse library, so users will never have missing VIs. zid="55">

But, there are scalability concerns

The solution is a modular system

What is your experience?

• Do you have an effective LabVIEW reuse system?
• What does your system look like?
  • Is your system monolithic or modular?
  • How big is the library?
  • How many developers contribute the the library?
  • How do you manage your installation?
• Are you feeling any pain points?
• How do you plan to solve them?