Refactoring Code

Last time I wrote a bit about huge projects. I glossed over it a bit.

Truth is, many big projects aren't fully or adequately spec'd out at the start, and come crunch time...let's just say that compromises are made.

So often you can look back at code and wonder who made that terrible design decision or atrocious wire layout. Why did this guy document his code so poorly? What the heck does that VI name mean? This page-long diagram could have been done with three nodes! And the list of criticisms goes on. Until you realize you're the one that wrote that VI.

Every now and then you get a great chance to rework an old peice of less-than-optimal code. I am fortunate enough right now to have that times two. I have the big project that's just about almost got the complete confidence of the customer. In the mean time, there's the immediate follow-on from the big project, which is a clone of the first with enhancements. At the same time, there's a separate project for a different group in the same company that intends to leverage a large part of the original big project.

This means that I'm making additions to the main project at the same time as borrowing sub VIs for another project. It's a really eye-opening opportunity. When you delete all but a dozen nodes from a ten-state state machine VI to replicate the functionality of that VI in another project, you really start to wonder about the tradeoff between overhead and flexibility.