[rzzzt]

Do you keep the project runnable at all times when you rewrite? My issue is twofold:

1) You can not do anything with the pieces until they are back together

2) If everything goes well, you get to see the exact same behavior as before. It can be faster, easier to modify or add stuff, perhaps even more elegant on the inside, but it will still be the same application.

[colonCapitalDee]

Not the person you originally asked, but I have the same rewriting habit.

Automated tests are essential for rewriting code. If I want to rewrite untested code I either add tests or don't rewrite it. The rewritten code also needs to be tested.

Whenever possible, split up big, untestable rewrites into a series of smaller, testable rewrites. Let's say I want to rewrite component A with subcomponents B and C to use some new library Foo. I might first rewrite B to use Foo, then rewrite A (and A's tests!) to work with rewritten B. Then I rewrite C to use Foo, then rewrite A again to work with rewritten C. Then I finally go rewrite A to use Foo. This is more coding then doing the whole thing in one go (I rewrote A 3 times!), but it's a net time saver because when I make a mistake I can quickly find and fix it.

When I'm on the clock I rewrite code for practical reasons (maybe the current structure of the code can't support some new requirement, or technical debt has gotten high enough to make maintenance difficult, or whatever). This is rare-ish. Rewriting code, especially production code, is risky and time consuming and just generally not worth it.

Most of the time when I rewrite code I'm rewriting my own code, and I'm doing it for personal reasons. I like good code, I like reading it and I like writing it. To me code has aesthetic qualities, code can be beautiful and elegant. It's also educational. Imagine a writer that never edits their work; they're probably not a very good writer. It's also fun! I'm already familiar with the problem domain, so I can devote my entire focus to solving the problem instead of splitting my attention between solving the problem and figuring out wtf is going on.

[kitsunesoba]

For #1, yeah I do. If I'm working on more routine/boilerplatey parts I might go a little longer without running, but it's pretty important to me to verify that each bit is working as expected before moving on. It's easy to wind up in a mess if I'm operating on the assumption that what's been written so far all works.

For #2, yeah that's true, but for me less visible improvements are gratifying, because not only is the thing being rewritten being improved, but I can also apply learnings to other projects that make rewriting them less necessary. Also, it just bugs me when there's reasonable obtainable improvements in optimization, flexibility, etc that I've left on the table… feels like I left the job half-done which isn't a great feeling.