There's a significant difference between the two statements "I don't get this code, it's crap, let's rewrite it." and "I understand this code, it's crap, let's rewrite it".
There are cases when the code is a convoluted, buggy, unintelligible, undocumented, untested and untestable mess. In those cases re-analyzing what it should do and re-implementing it from scratch is often both faster and more reliable way of dealing with required changes. Especially if you consider resources spent on maintenance over a significant period of time.
At this point, I get the nasty feeling that many people who preach "don't ever rewrite" mantra are the people who have produced large volumes of code in the past, but consider themselves too "senior" to maintain it now. The common rhetoric regarding "young/junior programmers" only confirms that notion.
Analyzing what the code should do is insufficient. You must also know what it does do. Somewhere, someone is depending on that and they will be angry when your rewrite, perfectly spec conforming though it may be, doesn't work the way it used to work.
Any change to a badly written application can break some obscure functionality or integration. I repeat, any change. Assuming that you're still working on the codebase in question (and why else someone would care to rewrite it?) there is a constant threat of breaking changes. Heck, with certain types of code regular issues after updates are nearly inevitable.
If you rewrite something, you will at least have understanding of how things work right now, which allows you to quickly and reliably deal with surfacing compatibility issues. On the other hand, updating legacy code to deal with those issue is a) much slower b) likely to introduce other issues.
And no, you cannot always slowly refactor old code. That is, in many cases it will take several orders of magnitude more time that a complete rewrite with new features plus all the rewrite issue mitigation.
Been there, seen that. Many times. So far I haven't regretted a single rewrite I've done in my professional life. If your experience is different, than maybe, just maybe, you should look at how you approach rewrites, rather than dismissing the whole concept as "wrong".
I don't think things should be painted as black or white as being either right or wrong.
A rewrite can be the best thing to happen to a code base, but it is not a panacea for all code quality problems. Sometimes a refactoring is simply a better option.
There are various reasons that factor into this decision, a good one being, as you mentioned, the assumption that you're still working on the codebase in question.
>>At this point, I get the nasty feeling that many people who preach "don't ever rewrite" mantra are the people who have produced large volumes of code in the past, but consider themselves too "senior" to maintain it now. The common rhetoric regarding "young/junior programmers" only confirms that notion.<<
I imagine the real reason is because the senior people have been burned to no end by trying to rewrite code they themselves did not understand.
There's nothing worse than realizing that you spent a whole bunch of time reimplementing something someone had already built when you could have simply taken a fraction of that time to understand why it was the way it was and, if applicable, to extend it to do whatever else you needed.
This also goes for looking for existing libraries to implement a feature before deciding to write your own. You still might need to write your own if you don't find something that fits, but sometimes you can save yourself a ton of work.
The only saving grace for having wasted all that time is learning the lesson that it's a waste of time and being able to apply that lesson usefully going forward. It's possible to go too far down that road and be too afraid to mess with existing code, but that line is actually in a very different place than I thought it was 10-15 years ago.
There's nothing worse than realizing that you spent a whole bunch of time reimplementing something someone had already built when you could have simply taken a fraction of that time to understand why it was the way it was and, if applicable, to extend it to do whatever else you needed.
There is something far worse. Spending years of your life to maintain a software version of Rube Goldberg Machine that performs mostly trivial things, but has insane accidental complexity.
At least when you re-implement something (even if it's been done before), you gain a better understanding of general ideas behind it.
Yes, but if you're going to replace it, then you really, really want to take the time to understand why it was the way it was.
Sometimes, you really do run across things that could never make any sense to anyone who knew better, like the famous Daily WTF example where someone created a website for a restaurant by printing out the page design for the paper menu, laying it on a wooden table, taking a picture of it, and uploading the picture. But other times -- much more often, in my experience -- you run across hidden technical challenges and limitations that led to what look like really stupid decisions until you understand the real motivation. And even when there were some really stupid decisions, it's often better to leave the system largely intact while you incrementally fix the stupid parts.
And, as I said before, sometimes it really does make sense to go in and start over. It's just that the line for when it's warranted may not be where you think it is.
As far as learning things go, providing your own implementation to solve a problem can be a great learning tool. Likewise, writing your own compiler, database, or web server can be an absolutely fantastic means for understanding these tools better. But it will rarely be the best means of solving a problem that requires a database-backed web application.
Reuse production-proven existing code and tools wherever you can when you're on the clock for a job or building a company, and teach yourself how things work on the side. If you build something so good that it's worth swapping in for the original and going through all the steps to bulletproof it for production, then awesome. If not, then you've still learned what you cared about learning.
It is very important to consider why the code turned into such a mess to begin with. Chances are same issues will happen again with the new codebase. If code generally turns worse over time, then the problem is not the actual code.
Developers are quick to think "some idiot must have written that" just because code is convoluted and ugly. But it might as well be smart competent developers working in firefighter mode, developers being shifted around from project to project with not enough time to get acquainted with the codebase, and so on. If these are the reasons a rewrite will not help.
There are cases when the code is a convoluted, buggy, unintelligible, undocumented, untested and untestable mess. In those cases re-analyzing what it should do and re-implementing it from scratch is often both faster and more reliable way of dealing with required changes. Especially if you consider resources spent on maintenance over a significant period of time.
At this point, I get the nasty feeling that many people who preach "don't ever rewrite" mantra are the people who have produced large volumes of code in the past, but consider themselves too "senior" to maintain it now. The common rhetoric regarding "young/junior programmers" only confirms that notion.