08-27-2018 08:59 AM
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.
08-27-2018 09:35 AM
"When you do things right, people won't be sure you've done anything at all."
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
08-27-2018 09:37 AM
@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
08-27-2018 09:40 AM
@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)
Ben
08-28-2018 04:32 AM
08-28-2018 09:29 AM
wiebe@CARYA wrote:
@Gregory wrote:
After reading this post ...
Good article, Joel's always a good read. This rang a bell, not sure why :
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.
08-29-2018 02:44 AM
@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 :
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).