LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reusable Code in LV.

Knowing when to re-write is an impossible thing.  We all have our own opinions which we can base on facts, but we never really KNOW because there are just too many assumptions in the process. We can only try to minimise the chances that we're choosing the wrong time to do it (or not do it).

 

Of course being fast and efficient in re-writing helps push things into that direction.  And being able to document what the old code does is kind of a hard prerequisite.  I've attempted to re-write things in the past and have found out after some time that additional undocumented "features" (using the term VERY lightly here) were actually being depended upon in the rest of the software.  Once this kind of thing sets in, you no longer are able to re-write portions.  It becomes an all-or-nothing exercise.

 

Most of my time is now spent properly drawing lines in the sand in preparation of that wonderous day where a re-write becomes really feasible, or required, like a transition to NXG.  I believe this work will eventually pay off many-fold.  Whether I'll still be around, I don't know.  Whether anyone will even recognise the work I put in, I also don't know.  But I know, and that's important.

0 Kudos
Message 21 of 27
(1,267 Views)

"When you do things right, people won't be sure you've done anything at all."

Message 22 of 27
(1,258 Views)

@Intaris wrote:

Knowing when to re-write is an impossible thing.  ...


I can think of one time that I KNEW that code needed a rewrite.

 

I had developed a HAL that was LVOOP based dynamic class instanciation blah blah blah.

 

I went on vacation and one of my peers learned that the customer wanted an exe. He was in deep $heit trying figure what need to be included in the build.

 

When I learned what I had put him through I threw the LVOOP code away and started over again in non-LVOOP. The new version is easier for the les experienced developers to support and I have not regretted it.

 

So if I am screwing my peers,  am doing something wrong.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 23 of 27
(1,255 Views)

@Hooovahh wrote:

"When you do things right, people won't be sure you've done anything at all."


"The problem with writing perfect code, is nobody will have a reason to look at." (Ben Rayner)

 

Spoiler
When I was in college and doing the electronic labs, my partner and I worked hard to get everything perfect. Before long we realized the TA was not reading what we wrote and put it the test. We made entries like "The TA never reads this stuff" Those entries were never noticed.

 

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 24 of 27
(1,252 Views)

@Gregory wrote:

After reading this post ...


Good article, Joel's always a good read. This rang a bell, not sure why Smiley Very Happy:

 

They did it by making the single worst strategic mistake that any software company can make:

 

They decided to rewrite the code from scratch.

Message 25 of 27
(1,208 Views)

wiebe@CARYA wrote:

@Gregory wrote:

After reading this post ...


Good article, Joel's always a good read. This rang a bell, not sure why Smiley Very Happy:

 

They did it by making the single worst strategic mistake that any software company can make:

 

They decided to rewrite the code from scratch.


These are all HUGE generalizations.  You have to asses the risk/reward (financiers call this ROI, or "Return on Investment") for each project you work on.  The more complicated I think a project is, the more hesitant I am about rewriting it.  Surprisingly, the more undisciplined the code looks, the more hesitant I am to rewrite it, also.  If it's that undisciplined, who knows what really lurks beneath the surface of that murky code?  If the murky code is something I'm adding features to, I may clean up the code that my addition immediately affects, but that's it.  I feel a little better if that code is already compartmentalized in some structure because I can be pretty certain the cleanup isn't going to produce an unknown change in dataflow.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 26 of 27
(1,184 Views)

@billko wrote:

wiebe@CARYA wrote:

@Gregory wrote:

After reading this post ...


Good article, Joel's always a good read. This rang a bell, not sure why Smiley Very Happy:

 

They did it by making the single worst strategic mistake that any software company can make:

 

They decided to rewrite the code from scratch.


These are all HUGE generalizations. 


Of course.

 

We still get requests from companies if we can finish projects that interns made (to save money). Not all interns screw up, but from the projects we get to see (not sure where to place what we don't get to see), 80% needs complete rewrite.

 

One remark from the article is typical. Joel seems to reason that if the code is really bad, it's harder to read then to (re)write, so it's better left alone. I'd say that depends. However, sometimes terrible code does simple things. If the intention of the terrible code is clear, I'd definitely go for a rewrite.

 

Of course there are many factors, like available budgets, time, head count, knowledge, etc..

 

And although this was a sneer at NXG, I can fully understand and support the decision. They are making great progress now the basis is laid out. And the rewrite isn't even a total rewrite, they are recycling the RTE (at least for now).

0 Kudos
Message 27 of 27
(1,142 Views)