I enjoy coming back to re-read this article every few years, because it's one of the rare things that I continue to agree with every time.
Joel mentions the "build one to throw away" mantra, and notes that it can be dangerous, but I'd go further with that: assume the "prototype" you build is going to be the product, and it will never get thrown away and rewritten. Because that's often what ends up happening, and you (and your colleagues) will be much happier working over the next many months or years inside a project where there was at least some thought given to architecture and abstractions when it was started.
The only time where I think a rewrite might be warranted is if you, no matter how hard you profile and work on it, have realized that the framework (or even language runtime/interpreter) you have built on is just not going to give you the performance you need. Even then, you should really be sure that you can't optimize it better, even if that means digging into the framework you're using to make changes. (Digging into the language runtime or interpreter might be a step too far, though, depending on the circumstances.)
Ok, I guess there's one more time: if the architecture of the code is just so completely wrong that you can't add new features or fix issues anymore, and your velocity completely drops to zero. And you are pretty sure that starting from scratch would get you to feature parity faster than embarking upon a series of gigantic refactors. But even then, I think most people underestimate how long that rewrite will take.
But otherwise... nah, it's probably not worth it, unless you're doing it on your own time, as a toy project, for learning or just fun. I might take an old personal project written in C and decide to rewrite it in Rust because I'm sick of C, and just don't care to work on it anymore, even though there are more things I want to do with that project. Now, I'm not saying that's necessarily a good reason to do it, but if I have no professional obligations around that code, it's my prerogative to spend my time however I want.
Joel mentions the "build one to throw away" mantra, and notes that it can be dangerous, but I'd go further with that: assume the "prototype" you build is going to be the product, and it will never get thrown away and rewritten. Because that's often what ends up happening, and you (and your colleagues) will be much happier working over the next many months or years inside a project where there was at least some thought given to architecture and abstractions when it was started.
The only time where I think a rewrite might be warranted is if you, no matter how hard you profile and work on it, have realized that the framework (or even language runtime/interpreter) you have built on is just not going to give you the performance you need. Even then, you should really be sure that you can't optimize it better, even if that means digging into the framework you're using to make changes. (Digging into the language runtime or interpreter might be a step too far, though, depending on the circumstances.)
Ok, I guess there's one more time: if the architecture of the code is just so completely wrong that you can't add new features or fix issues anymore, and your velocity completely drops to zero. And you are pretty sure that starting from scratch would get you to feature parity faster than embarking upon a series of gigantic refactors. But even then, I think most people underestimate how long that rewrite will take.
But otherwise... nah, it's probably not worth it, unless you're doing it on your own time, as a toy project, for learning or just fun. I might take an old personal project written in C and decide to rewrite it in Rust because I'm sick of C, and just don't care to work on it anymore, even though there are more things I want to do with that project. Now, I'm not saying that's necessarily a good reason to do it, but if I have no professional obligations around that code, it's my prerogative to spend my time however I want.