[bmitc]

I've done it myself several times, but of course on projects small enough for a single developer. I also think the approach of rewriting bits and pieces over time works. You can identify pieces of the old code base that has well-defined behavior and can be split off with a well-defined interface between the new and old code. This has the added benefit of both needing to understand the old codebase and what you'd ideally want from a new codebase.

[ojkelly]

This is one of the foundational concepts behind microservices.

A service small enough that a team or engineer can rewrite it in a cycle/sprint.

When it’s bigger than that, you have the compounding effects of other systems that interact with each other.

[object-a]

For microservices, the "rewrite" fallacy usually takes the form of:

"Why are there so many small services running? Surely we can shut down / delete/ merge together a bunch of them to clean things up"

I'm pretty sure Elon has also hit this fallacy during his tenure at Twitter.

[Jcowell]

> "Why are there so many small services running? Surely we can shut down / delete/ merge together a bunch of them to clean things up"

It’s such a Weird fallacy since I feel like the entire point of Microservces is that there’s an inherit reason they’re microservices in the first place.

If you don’t know why, you investigate why. It feels far easier to make a monolith than a microservice.