4 ms·

> 1. Are you ready to throw away all that knowledge? This is a massive fallacy. Rewriting code does not have to throw away knowledge. The old code is a speci

> 1. Are you ready to throw away all that knowledge? This is a massive fallacy. Rewriting code does not have to throw away knowledge. The old code is a specification for the new. You just have to read it. I've been involved in several successful rewrites and I always use the old code as a precise description of how the software is supposed to work. You have to take the time to understand it. And if you don't understand the old code, you really shouldn't be rewriting it.

deleted 7y ago
[deleted]
AnimalMuppet 7y ago
The code as "precise" description: The problem is that you can't tell if that weird "if" is correctly handling a corner case, or incorrectly handling a corner case, or is now a "can't happen" left behind after something else changed. You can't tell which from the code. That means that tribal knowledge is crucial for a successful rewrite. And that means that you need to do the rewrite while you still have that knowledge available.
- jcoffland 7y ago
  I don't agree. The code may not do precisely what was intended but it is deterministic. If you understand the language, you can understand the code.
  - AnimalMuppet 7y ago
    Yes, you understand what it says. You don't know what it should say, though. The code can't tell you that. [Edit: "Better architecture, but bug-for-bug compatible" probably isn't the goal of the rewrite.]
    - jcoffland 7y ago
      > Better architecture, but bug-for-bug compatible" probably isn't the goal of the rewrite. Why not? From there you proceed to fix the old bugs.
- switchbak 7y ago
  This is a good reason to have decent, intent revealing tests. Even if the code descends into a ball of mud, you still have the tests characterizing what the function of the system ought to be, allowing a rewrite with more than just blind faith and seat of your pants optimism. Then again, code bases with suites of extensive tests probably tend to not be the real worst cases. But if they are, at least you have the tools to do lots of iterative/evolutionary refactoring. It's amazing the radical transformations that crappy code can go through when you gain confidence from good tests. Having done huge multi-year refactoring efforts in both scenarios, I know which one I'd prefer.

deleted 7y ago

[deleted]

AnimalMuppet 7y ago

The code as "precise" description: The problem is that you can't tell if that weird "if" is correctly handling a corner case, or incorrectly handling a corner case, or is now a "can't happen" left behind after something else changed. You can't tell which from the code. That means that tribal knowledge is crucial for a successful rewrite. And that means that you need to do the rewrite while you still have that knowledge available.

jcoffland 7y ago
I don't agree. The code may not do precisely what was intended but it is deterministic. If you understand the language, you can understand the code.
- AnimalMuppet 7y ago
  Yes, you understand what it says. You don't know what it should say, though. The code can't tell you that. [Edit: "Better architecture, but bug-for-bug compatible" probably isn't the goal of the rewrite.]
  - jcoffland 7y ago
    > Better architecture, but bug-for-bug compatible" probably isn't the goal of the rewrite. Why not? From there you proceed to fix the old bugs.
switchbak 7y ago
This is a good reason to have decent, intent revealing tests. Even if the code descends into a ball of mud, you still have the tests characterizing what the function of the system ought to be, allowing a rewrite with more than just blind faith and seat of your pants optimism. Then again, code bases with suites of extensive tests probably tend to not be the real worst cases. But if they are, at least you have the tools to do lots of iterative/evolutionary refactoring. It's amazing the radical transformations that crappy code can go through when you gain confidence from good tests. Having done huge multi-year refactoring efforts in both scenarios, I know which one I'd prefer.