I know someone has run into this before

[Taggart]

So I've gotten stuck maintaining/upgrading someone else's code (they retired).  The code works, but its complete spaghetti.  The project manager (who is not a programmer)  thinks the guy who retired is a Labview expert because he somehow managed to make it work. 

Anyway my point is everytime I say something to the project manager about taking some time to clean things up and make it understandable, his answer is "It works, blah, blah, blah.  There's no need to spend any money fixing it.  If you can't understand what's going on, talk to the guy who wrote it (who is still around even though he is retired)"  In the meantime though, any time he asks me to do any kind of upgrade/maintenance it takes me at least a week to figure out what is going on (It even takes the guy who wrote it a week to figure out what is going on), and I usually end up with all kinds of crazy race conditions due to all the global variables.

Even the guy who wrote the code agrees that it needs to be cleaned up.  He claims he's never had the funding to fix it.  My question is how do I get the project manager to realize that in the long run it is worth it to spend some time rewriting/editing the code and making it more understandable and more robust?  This is a program that has been around for years and we're continuing to sell it.  And we are going to have to maintain it for years to come.  In my mind the manager is being very short-sighted.

[Albert.Geven]

Hi

You are right. Your manager is shortsighted. But the only way to get out of this situation is to claim time.

And each time he refuses to give time, simply say that he is wasting time on maintaining a badly written program.

Compare this with a car that is old and waggy but still drives. It needa a new engine but it still drives.

I want to help by offering help to you but the first step is in making your manager feel this is a dead end.

[Elijah_K]

Your manager may not appreciate just how bad this code is because he doesn't realize what a well written application should look like.  I would consider doing a couple things:

1. Put together a proof of concept demonstrating the advantages of well written code.  I'm not suggesting you re-do the entire application, but merely a subset of it as an illustration of what is possible
2. Consider running static code analysis on your code using VI Analyzer.  When it fails a multitude of the tests, you can show the documentation to your boss to substantiate your claim that it has problems

The bottom line is that whether or not your boss knows LabVIEW, the more you can relate the cost of time to long-term savings and mitigation of risk, the more likely he is to fund your efforts.

Good luck!

[Ben]

Diagrams like that make me squirm.

Believe it or not, there may be a reason the code looks like that if it was originally developed in LV 5 or before. All GUI attributes (that what they were called before property nodes were introduced) had to be in the top level VI. This is one of the reasons I was very impressed by LV 6. Small monitors also encouraged those types of diagrams. A few "replace stacked seq with flat" follwed by a diagram clean-up would go a long way with this VI.

As far as the race conditions are concerened...

everytime you run into a race condition replace all offending globals/locals with Action Engines. Only replace as many as are involved in each problem. In the long run you will end up re-writting most of teh app and the rest... well we don't have to "wash the spare tire everytime the car is washed".

I have been maintaining code that looked very much like that code for years and with the upgrade to LV 8.2 I was able to finally get it cleaned-up.

Sorry I can't give a more convince reply.

Ben

[Ray.R]

I can fully appreciate that this is a sensitive issue with your boss.

I often get called to add one more feature to code that looks like the one you posted.  So far, I have not been able to convince the managers (who know little or nothing of LabVIEW) to clean up or re-write the code.  It all boils down to budget.

The one way I did clean up the code is that I implemented the new feature, thus taking 3 weeks in the original code.  Afterwards, I re-wrote the entire code in less than 1 week, optimized it and made it run 18 times faster while taking 1/10th of coding space.  They did not appreciate it...   My savings grace was the fact that I reduced the test from 90 min to 5 min.

The last contract was also a similar scenario.  Without looking at the code, I described to them the potential sources of problems their existing code.  I got the contract to optimize and cleanup their code.  When I saw it, I had well described what were the problem areas (having seen it so many times before with different clients).  I soon after discovered that the code was written by the Team Leader to whom I reported to and he was adament that the code remain the same and that it was well written in its current form..  I was then given the task of simply adding messy blocks of code to the already messy code.  I did do some cleanup and any new sub-vi's were well written and fully documented to show how well written code should look like.

All the above story to tell you that you may never convince the manager to do a cleanup job.  However, in your own investigation of the code, try to do some cleanup and transform some of the code to sub-vi's that you can manage and cleanup while adding new features and maintaining the code.  Over time, you can transform the code to something readable & maintainable.

Remember to try to have fun in the process...

R

[EdDickens]

I've seen and worked on a few of those as well.

I've had good luck convincing customers to do a complete rewrite by providing them two quotes.

The first one outlines what it will take to add the new features they want to the existing code. This one always includes a healthy chunk of time dedicated to analyzing and documenting the code so we know what's going on. Then we also put in a clause that says something like since we did not write the majority of the code, we are not responsible for any problems outside of the area we modified and will not provide any "warranty" work for those areas.

The second is for a complete rewrite with the added features. In this one we state that we will provide support for the entire application.

The cost of the complete rewrite usually is about the same as just adding the new feature to the existing code. So with the added support for the entire application, we've had pretty good luck getting to let us do the rewrite.

I realize this is an internal project for you so you don't have the opportunity to show such a comparison. But I'm hoping it might give you some ideas on how to approach your manager.

Elijah's ideas of a small proof of concept and running VI analyzer on it might be helpful. You might try downloading the Certified LabVIEW Delveloper Sample Exams (links below) and show him what a properly architected application should look like. These may not be perfect, but might be enough to let him see how much better it could be.

Sample Car Wash  Sample Traffic Light Control  Sample Security System

Otherwise, Bens suggestion of cleaning up as you go is probably the best.

Good Luck

Ed

[#7]

You said it yourself.  Budget, budget, budget.  Put a cost (in a dollar amount and time) for the small upgrade/maintenance and add in the time to "understand" what flavor of sauce is on that spaghetti.    If you manager only looks at cost, start showing him/her how much time is wasted but you must put a dollar amount down.

An alternative would be to spend some extra time cleaning up portions of the code as you go and use it a "learning/understanding" time.