Applying learning to a new project, now that is something different.
Applying learning to a new project, now that is something different.
If a re-write saves more time than it takes, then it should be considered. If it takes you a week to implement something that should be done in a day, and you realize that you'll be doing lots of those things over the course of the next few years, it's probably worth considering a re-write. It's not a solution to every problem, and it's probably done more often than it's not, but there are certainly times when it pays to do it. It's easy to have simple rules that say don't do things. It's much harder to make the best decision for the business. Just because some businesses in the past have made the wrong decision with regards to re-writes doesn't mean it's always wrong.
That said, when systems need to be re-engineered, completely thrown out and re-written, or a new feature needs to be cranked out to meet a business need, the developers who can design and create large coherent systems quickly is irreplaceable or very expensive. Constantly throwing your code out gives you this valuable experience.
This is commonly trotted out to discourage re-writes, but how does that square with another piece of common advice: "build one to throw away" ?
I'm genuinely curious, and I'm not trying to pick on you specifically. There are just many different situations where one or the other makes sense, so I don't think it's so cut and dried.
If you've written a program, but it doesn't work yet, and you've realized you made major architectural mistakes or whatever, feel free to rewrite from scratch.
If you've written a program and it's been in real use for a while, solving real problems for a lot of happy users, that means it embodies a lot of knowledge that will be difficult to re-create from scratch; in that case, think very carefully before embarking on a rewrite, and look hard for a way forward that will preserve that knowledge.