2 ms·

The project I'm working on now is at a point where it's either spend a HUGE amount of time refactoring and fixing everything or just start over. We can't just c

The project I'm working on now is at a point where it's either spend a HUGE amount of time refactoring and fixing everything or just start over. We can't just continue adding on features with the state the code is in. The question is, which will be faster? Right now, it's written to run on an old OS, with old versions of old languages. We absolutely HAVE to update this stuff as it's just stupid to continue programming in the dark ages (no code completion, no jump to definition, printf debugging). But is it better to refactor the code and rewrite it slowly, or just scrap it, lose all of the old terrible design decisions, and move on. You ask the question "Why do you think you'd make the design decisions correctly this time around?" Well, we didn't write the first version. It was given to a vendor that totally botched the job and it's our responsibility to fix it.

mgkimsal 14y ago
"We absolutely HAVE to update this stuff as it's just stupid to continue programming in the dark ages" There might also be security issues. I've found that's sometimes a good rationale - if I've got code that will only work in PHP 4.1, and it's gotta work for the next 5 years, probably rewriting ('wholesale refactoring') is a much more prudent choice, even though it's "a complete rewrite". There will be no security patches for the underlying language - building on a platform with known and 'never-will-be-fixed' security holes isn't a good long-term strategy.
MartinCron 14y ago
My experience says that for real legacy code (deployed and actually used) it is almost always better to slice it up and re-write and deploy sections of it incrementally. Big-bang transitions with a "point of no return" are just so expensive and risky. Yes, you lose "conceptual integrity" and your UX may be inconsistent in the transitional time, but those are small prices to pay.

mgkimsal 14y ago

"We absolutely HAVE to update this stuff as it's just stupid to continue programming in the dark ages" There might also be security issues. I've found that's sometimes a good rationale - if I've got code that will only work in PHP 4.1, and it's gotta work for the next 5 years, probably rewriting ('wholesale refactoring') is a much more prudent choice, even though it's "a complete rewrite". There will be no security patches for the underlying language - building on a platform with known and 'never-will-be-fixed' security holes isn't a good long-term strategy.

MartinCron 14y ago

My experience says that for real legacy code (deployed and actually used) it is almost always better to slice it up and re-write and deploy sections of it incrementally. Big-bang transitions with a "point of no return" are just so expensive and risky. Yes, you lose "conceptual integrity" and your UX may be inconsistent in the transitional time, but those are small prices to pay.