If the question did arise for rewrite, it needs rewrite !!
When apps grow, features are added and old features remain in code but are obsolete. Every other products where app connects also have new versions and better features, and your app contains code to overcome lack of those features.
While rewrite, you already have list of all useful and useless features so you can design it correctly. This brings benefits of unit testing, typically in young app there is no scope of unit testing when features are changing dynamically. Typically in product lifecycle, earlier age is spent in acquiring customers and product constantly changes due to feedback and internal code becomes mess !!!
After product has become mature, it needs rewrite because you have time and money to rewrite. Also you don't need to rewrite everything !! You can substitute every services with newly designed micro services.
While rewrite, you already have list of all useful and useless features so you can design it correctly
Yes, that's a valid strategy and I think it relates to @phlashgbg
's comment about Carmack's quote.
Only one thing to keep in mind:
After product has become mature, it needs rewrite because you have time and money to rewrite. Also you don't need to rewrite everything !! You can substitute every services with newly designed micro services.
There are perfectly valid reasons for splitting a monolith into a microservices but it's not a given, in the sense that 20 microservices handled by 1 person are an anti-pattern.
The rewrite can be a modular monolith, a hybrid of a monolith with some serverless functions or a 100% microservice architecture, a totally serverless app or anything in between. It always depends on context and constraints.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If the question did arise for rewrite, it needs rewrite !!
When apps grow, features are added and old features remain in code but are obsolete. Every other products where app connects also have new versions and better features, and your app contains code to overcome lack of those features.
While rewrite, you already have list of all useful and useless features so you can design it correctly. This brings benefits of unit testing, typically in young app there is no scope of unit testing when features are changing dynamically. Typically in product lifecycle, earlier age is spent in acquiring customers and product constantly changes due to feedback and internal code becomes mess !!!
After product has become mature, it needs rewrite because you have time and money to rewrite. Also you don't need to rewrite everything !! You can substitute every services with newly designed micro services.
Yes, that's a valid strategy and I think it relates to @phlashgbg 's comment about Carmack's quote.
Only one thing to keep in mind:
There are perfectly valid reasons for splitting a monolith into a microservices but it's not a given, in the sense that 20 microservices handled by 1 person are an anti-pattern.
The rewrite can be a modular monolith, a hybrid of a monolith with some serverless functions or a 100% microservice architecture, a totally serverless app or anything in between. It always depends on context and constraints.