3 ms·

The paragraph on "legacy code" is a bit weak and half-hearted because it underemphasizes one of the most important arguments for using old code: it's been thoro

The paragraph on "legacy code" is a bit weak and half-hearted because it underemphasizes one of the most important arguments for using old code: it's been thoroughly debugged already. The most the author can summon on the topic is the fact that legacy code "takes uncertainty out of the debugging process." What? There is no debugging process, because that code has been debugged for 40 years and is damn near bulletproof at this point! Everybody is used to cringing when they hear "legacy code," and that's justifiable for several good reasons. Note that "not wanting to learn an unfamiliar language" isn't one of them. And "not having, or not being willing to use/cultivate, the skill set of reading someone else's code" isn't one of them either. But there is obviously a lot of bad code out there. And that's the thing, there are only two kinds of code: good code and bad code. And by extension there is bad legacy code and there is good legacy code. Don't assume legacy code is always bad code. If something has been used successfully for 40 years, do yourself a favor and try to have the humility to assume people implemented it well, found all the bugs, know what they're doing, and/or generally are rational-thinking adults who make good choices... instead of the usual naïve assumption that everybody's an idiot but I'm going to change all that! No, you're going to duplicate a lot of effort, and possibly (depending on the faithfulness of your reading of the code) reintroduce some of the same bugs that were dealt with years ago.

mushishi 9y ago
I don't know about mathematical domain, so this might be off-topic but in some cases a legacy code base that works perfectly can be brittle and full of holes and bugs that never manifested themselves because the code not directly interfacing the input data is guarded by subset of possible data it should support, and many of the possible code paths have not been evaluated. But if you try to refactor the code to, say support other feature or optimise it, you might get into nastiness that is beyond comprehension, and you cannot count on that the code is coherent or correct. This is my experience for maintaining a legacy base that has been many years in production. It's just a pile of frozen code that nobody has properly refactored probably out of fear for breaking something. This way you end up with unreadable layers and weird technology-specific hacks that were carefully made just work, probably not understanding what the existing code actually did but cargo-culting and resulting with massive amount of code that does little.

mushishi 9y ago

I don't know about mathematical domain, so this might be off-topic but in some cases a legacy code base that works perfectly can be brittle and full of holes and bugs that never manifested themselves because the code not directly interfacing the input data is guarded by subset of possible data it should support, and many of the possible code paths have not been evaluated. But if you try to refactor the code to, say support other feature or optimise it, you might get into nastiness that is beyond comprehension, and you cannot count on that the code is coherent or correct. This is my experience for maintaining a legacy base that has been many years in production. It's just a pile of frozen code that nobody has properly refactored probably out of fear for breaking something. This way you end up with unreadable layers and weird technology-specific hacks that were carefully made just work, probably not understanding what the existing code actually did but cargo-culting and resulting with massive amount of code that does little.