[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.