5 ms·
True, but Joel's point is that a rewrite can actually be bad for the code not just the business, because you throw out years of real-world testing and bugfixes.
by gommm 17y ago
True, but Joel's point is that a rewrite can actually be bad for the code not just the business, because you throw out years of real-world testing and bugfixes.
I think that applies on project with multiple developers and whose developers are not in the company anymore. When it's a solo developer, he still has the experience and doesn't lose so much from throwing out the code
- DougBTX 17y agoThere's truthyness in that statement... but I've re-written code from years before that I wrote myself; it's easy to forget all corner cases you handled in old code. It forces you to take a step back from your new, clean, way to solve the problem and make sure it really does cover those forgotten cases too. The added uncertainty really hurts the predictability of a re-write.
- bmelton 17y agoA little offtopic, but I would say this is the reason that vigilantly commenting your code is essential, especially for a one man shop. I've learned this the hard way enough times to make it stick to the point now that even when I'm just writing regular, mundane CSS, I make sure to comment in every workaround I write, no matter how routine. It takes longer, but it's worth saving me from myself.
- rbanffy 17y agoThat's why you should write automated tests for your corner cases (and of course not only the corner cases). If all corner cases you knew about are properly tested, your rewrite should function properly.