[mojuba]

I once rewrote a monstrous app that was in development for 5 years (!), in just one month. In terms of LOC it was 20 times smaller than the old codebase. Had the same functionality and then some more. It had zero bugs in the first release, compared to myriad of bugs in the previous one (mostly multithreading related - yes it's hard).

All I did was, I dumped Microsoft's COM/DCOM and replaced it with REST; also replaced C++ and VB with C#. Totally made sense to rewrite from scratch and it was a big win with absolutely no downsides. Like, no downsides whatsoever because otheriwse the same month I would have spent fixing maybe 4 or 5 multithreading bugs in the old codebase.

Anyway, never say "never do X" because you are most likely wrong.

[gfodor]

I think this advice is not relevant if you are on a project where it's feasible for a single developer to re-write it in a month. Burning a month on a failed re-write is certainly worth the risk if you take a run at it.

For projects where there are several devs going to be working on the re-write for a long time, it almost certainly is a sign that the 'legacy' code has way more knowledge embedded in it than it might seem. Having been on the death march of a re-write before I think the signs are usually obvious when you're in one scenario or the other.

[citrin_ru]

> the 'legacy' code has way more knowledge embedded in it than it might seem.

Cannot agree more, but when knowledge embedded only in the code and not in comments/commits and documentation it is a problem even if you don't plan for re-write.

It is very disappointing to hear from otherwise good programmers statements like: "good code doesn't need comments (and my code is good)". As a result we have code where some line can captures hours of research and/or discussions, but there are no comments and commit logs are too brief. After a year even an author usually cannot say why it was done this way.

[perl4ever]

>I think this advice is not relevant if you are on a project where it's feasible for a single developer to re-write it in a month

The implication is that is can be non-obvious if something is potentially that sort of project, as it originally was a large undertaking. I mean, you can assume it's a fake story, but they said it wasn't originally a one person, one month thing.

I don't know that it implies the person who rewrites something is a super-genius, it's just that sometimes a new perspective or tools allow a really amazing improvement.

[gfodor]

Yeah I was referring to the posterior - eg if your project could be rewritten by one person in a month (unbeknownst to you beforehand) then the advice is irrelevant. Hence it’s worth attempting a re-write in some cases to determine that, and failing fast.

[mamcx]

This is my experience too. I rewrite often and liberally, and even switch langs (on the side) to check if it can bring huge gains.

[allenu]

I agree. With the right tools, expertise, and design, rewriting is absolutely an option. I've learned over the years that it's often better to just rewrite some crufty, old code entirely than to try to understand the old code to patch it up. This requires a very good understanding of the requirements, which have often changed from the original code, to come up with a better design for the present needs.

Of course, this doesn't apply in all cases, but "never rewrite" is a limiting strategy.