Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Controversial thoughts on reuse

Active Participant

Hello Programming Compatriots,

I'm full contrarian mode now but rather than just dismiss the arguments out of hand think about your own experiences, you may find I'm not so contrary after all.

The caveat on this discussion is that at SSDC we do not repeat many projects, stepping away from the test arena has made our world a more varied place, less friendly to re-use.

Way back in article 28 I trashed the traditional way re-use is taught/advertised in the LabVIEW world in this article here.

Our technique of keeping everything in the project works very nicely for us over all of our 100+ active projects. Issues are extremely rare. But our evolved practice still puts us at odds with traditional programming best practice in one area.

Looking at the traditional view of reuse and to clarify I'm speaking about planned functional reuse here. Planned functional reuse differs from ad-hoc (opportunistic reuse) in the levels of effort expended by teams to manage the reuse library.

"Planned reuse — This involves software developed with reuse as a goal during its development. Developers spent extra effort to ensure it would be reusable within the intended domains. The additional cost during development may have been significant but the resulting product can achieve dramatic savings over a number of projects. The SEER-SEM estimation model shows that the additional costs of building software designed for reuse can be up to 63 percent more than building with no consideration for reusability." D Galorath

Computer Science books tend to say that good practice is to manage a reuse library of highly reusable components with your team, these are tested, documented and approved. We also bend our architectures into a shape that will allow us to plug in reusable components. Finally we have to maintain this library across new versions of the software, operating system, hardware etc etc.

As a consumer of the reuse library we have to trust it will work in a new environment, giving 100% functionality (or allowing us to extend functionality).

So how many programmers have I met that enjoy maintaining a reuse library and all the effort that entails? Let me count them on the fingers of zero hands!

All of these measures of efficiency have been focused on software languages that take a considerable effort to add functionality, how does working in an environment like LabVIEW change this dynamic?

Thing is LabVIEW is rapid, I can hand crank a driver in very little time, I know it is 100% of what I need (and no more). Because it is stripped down, I'm not lugging a vast weight of unnecessary functionality with me. Multiply this by 20 pieces of hardware and it's probably a significant size improvement, which is a bonus.

The argument against this point of view is fairly strong, a reused component should be better tested, more stable, better understood etc etc. Well this is possibly true if you work in an environment where you are churning out variants of the same project. My response would be, if this is the case branch and adapt the entire project.

Interesting Article-->"Maximizing reuse complicates use"<-- Interesting Article

In the past I really bought into the whole reuse thing, investing a significant effort in pulling out useful stuff and maintaining a repository. I don't even know where it is any more, it's all a bit sad. I wonder how many man-hours have been wasted on reuse libraries full of old code for obsolete hardware on out-of-date versions of LabVIEW.

But sure Stevey, a company as awesome as SSDC must reuse loads of stuff, is a question I've never been asked. If I was, I would say YES we reuse entire project templates, documentation, methodology specific templates. Where we have identified projects that will have possible repeats we generate a project template. I view this as architectural reuse rather than functional reuse and it's an amazing time saver, standard enforcer and competitive advantage. Pretty much everything else is ad-hoc and unmanaged.

ooooooh controversial, hope I've rocked your worlds.

Lots of Love

Steve

"Code reuse results in dependency on the component being reused. Rob Pike opined that "A little copying is better than a little dependency". When he joined Google, the company was putting heavy emphasis on code reuse. He believes that Google's codebase still suffers from results of that former policy in terms of compilation speed and maintainability" wikipedia

Comments
Active Participant

I don't believe I can honestly disagree with anything you've said here.  Your observations regarding the administrative costs of reuse match what I've seen here in NI Systems Engineering.  That's even called out in the principles of package design:  the first consideration in package development is just how much clerical and support effort you are willing to spend.

For us, I think that is a worthwhile effort.  We have a large customer base, even within specific industries, and we have more opportunities to see potential for reuse.  By spending a few or even a few tens of hours on a bit of reuse code, we can accelerate customer development and reduce our own support burden.  Your mileage clearly varies.

Now, one thing that struck me about your post was this:  "In the past I really bought into the whole reuse thing, investing a significant effort in pulling out useful stuff and maintaining a repository. I don't even know where it is any more, it's all a bit sad."  Please correct me if I'm wrong, but that feels like "I *think* I'm going to reuse this, so I'll make the investment."  Would things have gone differently if your approach had been "I've written minor variations of the same dang thing five times, because it always comes up.  Can I write it a sixth time and be done?"

The former is closer to Big Design Up Front, and you know how I feel about that.  Perhaps a small shop like yours, which always has to worry about overhead, would be better off taking a more organic, needs-driven approach.  One of what I consider to be my best bits of reuse code is the direct result of the latter; I wrote it on spec, because I had written a substantially similar module before, which I *had* successfully reused, and I knew I'd use it again.

An early mentor of mine was also heavily invested in the concept of reuse, but in the time I worked with him, we never wrote reuse code on spec.  His plan for developing reuse content was this:  when working on a project identify portions of the code that have the *potential* for reuse, and flag them.  During development, code as if you might develop those items as reuse code at a later date (he expressed this as "do 80% of the work you would need to do for reuse").  Then, if you need one of those items in the next project, spend your development time for that portion of the code doing the rest of the work (the last 20%).  You *should* still be ahead on time.  Do updates as necessary, usually when you can tie it to a customer project.  And allow for the reality that some of your reuse items will fall by the wayside in any given period.

Active Participant

Another thought (new thought, new comment) might be to focus less on pieces of user-facing functionality, and more on the "glue code" for your style of coding - the common coding tasks that show up in applications across industries.

The bit of reuse of mine that I mentioned in my previous comment is a network communications pipe for Actor Framework.  Pretty much any application distributed across targets (RT, desktop, etc) needs one of these.

At the risk of dating myself, I used Gary Johnson's original circular buffer VI in several applications over more than a decade.  (Gary Johnson the LabVIEW author, not Gary Johnson the presidential candidate.)

Maybe we're targeting the wrong things for reuse.

Active Participant

niACS wrote:

Maybe we're targeting the wrong things for reuse.


                   

I think you've nailed it, if you look at what we successfully reuse it's the glue. Also that's project glue too like documents and methods. This we actually do quite formally too.

Knight of NI

The other thing with reuse is actually getting people to use it.  I spent probably a half year developing a procedure and getting approval for tools to distribute and store for a reuse library.  I then spent all Christmas break putting it together.  And nobody ever used it...

I still use many of those VIs I worked on (they are all low level functions for things I had to do all the time, much like OpenG).  They have been slightly updated here and there, but the library was pretty solid.


There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

The discussions from the Advanced User Track is not over. Join in the conversation: 2016 Advanced Users Track
Active Participant

crossrulz wrote:


                       

The other thing with reuse is actually getting people to use it.  I spent probably a half year developing a procedure and getting approval for tools to distribute and store for a reuse library.  I then spent all Christmas break putting it together.  And nobody ever used it...


                   

You need organizational buy-in into reuse. Anything less is a waste of your effort and better spent on ad-hoc engineering.





Copyright © 2004-2017 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Active Participant

I think use case is a very important consideration here. By design we work in many different fields and for us it's not worthwhile at the lower levels. I think if we were more focused on test it may be a different story.

I think we may need some better definition of the parts of a project too. So by planned functional reuse I'm really talking about apis and drivers. Our planned reuse tends to be at the project level. So rather than have a library of vis I would have a fully formed project template.

Active Participant

Completely concur with this, I think for a company that specialises on a particular field or test system planned functional re-use will give a ROI. In fact I'd like to have more a feeling for the benefits of this as I've never worked in that environment.

For us it's more of a case of throwing smart people at a variety of problems and for this use case we've seen great advantage from planned project re-use and very little advantage from re-use of more granular bits of code in a planned fashion.

I think planned project re-use is also easier to manage in that it's essentially one repository for a particular project type rather than maintaining a library or cross-reference.

I think this is a fair summary of the point I'm trying to make.

Active Participant

With reuse one has to identify what will be of significant value to you in the future.   Sounds like you made some missteps in that before you identified the stuff you actually benefit from reusing.  What you eventually found sounds totally different to what I found reusable, but like you I don't spend time reusing very application-narrow drivers and things.  My reuse packages are broadly useful ones like SQLite, JSON, or Messenger Library. 

Active Participant

One basic difference is that there are 4 of us, so reaching for a reuseable API has to be a bit more formal.

That said, our template has equivalents of your SQLite and Messenger Library in it, so probably not as different as you think.