Help Manaing Large Amounts of Bad Code

[Lukin]

So I recently started a new job where I took over for someone who had been developing code for a test lab for over ten years.  It’s a lab that contains about ten different tests systems most of which are very complex.  From a user’s perspective (the tech running the tests and the engineers using the data) his code is great.  The GUI’s and methods for storing the data look and work great.  However his block diagrams are an absolute mess.  There are very few subVIs and virtually no documentation.  Frequently I can spread a block diagram across both of my two 1920x1080 monitors and still see less than a quarter of the code.  On top of this there is an immense amount of the bad code. 

As someone who normally writes very neat and well documented code it is driving me nuts and taking an incredible amount of time to understand even simple things.  Unfortunately taking the time to bring it all up to snuff is simply out of the question.  As I make upgrades to the systems I am updating small portions of code but it’s not even making a dent.  So I was wondering if anyone out there has inherited bad code and might have some tips on how to manage a mess like this.

Thanks   

[billko]

---

@Lukin wrote:

So I recently started a new job where I took over for someone who had been developing code for a test lab for over ten years.  It’s a lab that contains about ten different tests systems most of which are very complex.  From a user’s perspective (the tech running the tests and the engineers using the data) his code is great.  The GUI’s and methods for storing the data look and work great.  However his block diagrams are an absolute mess.  There are very few subVIs and virtually no documentation.  Frequently I can spread a block diagram across both of my two 1920x1080 monitors and still see less than a quarter of the code.  On top of this there is an immense amount of the bad code. 

As someone who normally writes very neat and well documented code it is driving me nuts and taking an incredible amount of time to understand even simple things.  Unfortunately taking the time to bring it all up to snuff is simply out of the question.  As I make upgrades to the systems I am updating small portions of code but it’s not even making a dent.  So I was wondering if anyone out there has inherited bad code and might have some tips on how to manage a mess like this.

Thanks   

---

I think one of the Core courses touches upon this.  Basically you start by fixing up cosmetic things (including organizing into subVIs) and end with actually changing code to be more efficient.  90% of my fixup time is doing the former - I try to stay away from the latter unless it is doing something absolutely incorrectly, not just inefficiently.  Even then I am very cautious, as there might be stuff down the line that will be looking for the incorrectly calculated data...

For instance, once I changed a preview queue to dequeue to make it more efficient, then when it didn't work, it was only then that I found the idiot was dequeuing the same queue in multiple places!!!

[johnsold]

I agree with Bill that incremental improvements are probably your best strategy.

Other comments:

1. Make backups of every piece of code that is presently working.  Preferably two copies three independent with at least one written to DVD and stored in a different building.

2. Always work on a copy.  Never change the original.  If you change something in the northwest corner of the diagram and find out when Magellan sails around the world that it had an unanticipated effect in the southeast corner, you may have a hard time going back.

3. Anytime someone requests a significant change in features or performance, or if a serious bug is identified, INSIST on rewriting the relevant code. It can take longer to "tweak" old code than to write a new program.  You decide what is a "significant" change based on whether you can see all the relevant code in one place on the diagram and how intricately it is connected to other code.

4. Anytime you identify what a section of code is doing, document it. Inputs, outputs, algorithm, special timing, data formatting...

5. Do not assume that the users actually know what the code it doing. It may not be doing what they think it is. Also, what they want and what it is doing may not be the same.  Try to determine real specifications before changing things.  I found bug in some ten year old code only when the users asked me to change something.  It had been in almost daily use thoughout that time.  (And I wrote the original code.)

6. Ask to see the recorded data and take a look to see if it appears to match what is expected.

7. Try to get some time on the system with the real test hardware so you can determine how things work.  Simulations without the hardware may be deceptive.

8. Keep management informed. They hate surprises worse than bad news.  If they are not aware of how much work a good test system program requires, you may need to try to educate them. This can be very important in cases of item 3 and item 5.

Good luck.

Lynn

[Hooovahh]

Use source code control.  Commit the code as it is, then fix things as they need to be.  Then you can perform a compare if needed and see the changes made, as well as the comments you put into souce code control.

Too many times I straddle the fence, and keep the crappy code just trying to add a new feature using what exists, because of the time needed to update/fix it.  I always regret it, and wish I had taken the time to re-write it.

[Lukin]

Thanks guys for the help. I was already doing the some of the suggestions. I think the tip about checking on actual spec first is a very good one. I have already found several major mistakes in the code and I think going forward it would be good for me to question just about everything. Also while I was already using it the tip about source code control is really important. I set it up my first day and it has already saved me several times.
Thanks again,

[Yamaeda]

As already mentioned, as soon as you identify a code section, make a sub-vi! I'm not in the "football field" code-inheritance, but old and messy code nontheless so i know your pain.

If you identify several bugs you can actually suggest rewriting the whole program in a better way, it'd probably be the same time as fixing bugs in the existing code and especially if you can show some sample of what it'd look like and they can "understand" the code they'll easily see the benefits.

/Y

[jcarmody]

Just keep in mind that rewriting is an extremely difficult proposition.  If you can determine that the current mess works and you understand the requirements, you'll still have to solve all of the little problems that the previous developer discovered and fixed.  Some of the unexplainable code you see might be solutions to odd corner cases that you won't see until you get very deep.

If your organization has a Software Quality Assurance process, a rewrite will/should be thoroughly audited.  Ouch.

I refer back to this article from Joel Spolksy whenever I consider rewriting production software - Things You Should Never Do, Part I  Having said all this, I've rewritten two pieces of complex (for me) test software and am happier for the effort.

[billko]

In cases of test software, at least, you shouldn't make changes that actually change the way something works - unless that is the reason why you are looking at the software in the first place.  Let's say you know the way they are measuring something is inefficient - or maybe even WRONG - so you do them a favor and change it - and then borderline units are suddenly failing instead of passing because your new, improved version is measuring it differently.  Guess what?  It's your fault because the original way - right or wrong - was the approved method for testing the unit.  Get approval for something like that - and make sure they understand the ramifications because sometimes they will nod like a bobblehead and not understand what you are saying.  Something like eliminating a for loop because you know a primitive will work directly on an array is fine, but something like substitituting a LabVIEW canned algorithm for code that approximates the real thing - not so good an idea.

Just another two cents of mine thrown in for good measure.  😉

[DFGray]

I once inherited a piece of code like this.  However, I had some involvement with it before I inherited it, so understood how it worked.  The code had grown organically through six programmers, with predictable results.  I needed to add a lot of functionality to it.  It was so brittle, we changed the calling code rather than change the code.  I spent two weeks refactoring it and another two weeks ensuring backwards compatibility.  The steps I took were:

1. Understand what the code is doing (probably your current biggest challenge)
2. Design an efficient structure to do what the code is currently doing
3. Write the structure
4. Copy the current code (subVIs, code blocks, etc) into the structure.  This maintains all the weird processing that may be taking place in the current code, although there may be timing issues.
5. Test, test, test

In the end, I was largely successful, but for error handling.  The new code properly processed and passed out errors.  The old code swallowed some errors, silently failing.  I made the call to not do that, and ended up taking some heat for it, since it showed up a lot of old bugs that then needed to be fixed.  But our customers probably appreciated working code.

After all this, I quadrupled the size and functionality of the code in fairly short order.  With the new structure in place, designed for extension, it was easy, and the code stayed stable.

For you to do something like this, you will need to create a development source code branch and pull one test at a time over in it to get reworked.  When the test is refactored to your satisfaction, you can replace the original test.  All of this will take time, so make sure your management is aware of what is going on.  If you are not allowed to do this sort of massive refactoring, you can start by creating subVIs in the current code and slowly reducing the block diagram size.  This will also help you refactor into a more efficient structure in the future, and will reduce the time it takes to do it.  I will second the above suggestion that when you have to fix something, try to get buy-in fix it correctly, even if it takes awhile.

Good luck!

[Hooovahh]

I've never used the unit test frame work, but it sounds like it is the type of thing that would help out with confirming the functionality of the legacy code is the same as the refactored code.