Folklore and common sense warn developers and teams against doing big rewrites.
To do or not to do
There are many reasons not to rewrit...
For further actions, you may consider blocking this person and/or reporting abuse
You should avoid complete rewrites at all costs. Try to find one small aspect in your legacy application and rewrite that. Then integrate that newly rewritten part in the old system. If you have integration tests for the old system, you can use them with the new code.
This has several advantages:
The downsides are that you cannot do this if you basically need a completely new system
Yeah, I feel a complete rewrite should be the last resort. It made sense in the example I linked to because they had unmaintanable software with no tests and they were going to run out of money.
Usually in a more established company when you accrue tech debt, you can rewrite/refactor in steps as you said.
This is pretty much the micro service mantra, driven by a need to uncouple change in different areas of a system so the team can keep up with unpredictable demands (or at least only short term predictions), without throwing everything out from the monolith on day one. Martin Fowler (him again!) describes this as evolutionary architecture.
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.
I think rewrites/redesign/refactoring have their place. It is important to evaluate exactly why it is needed and whether it is cost effective in the long run. For instance if scaling is a major issue then switching to a faster language might be worth it.
At my company we have a single web page that was originally written about 4 years ago and was made very dynamically for this one paradigm by one person. Then we added many many new features to that page that did not fit anywhere in the predicted paradigm. Add to that that different people of varying skills, style and experience have added to those features thus making it a monster of at least 20k lines of code for one page (not including libraries or the like). We are considering rewriting that page so that we can add new features (which are added constantly) in a quick and maintainable fashion.
Is it like a dashboard type of page? I can't fathom a single web page having 20k lines unless they're autogenerated or something.
If you consider "rewriting", can you consider splitting it as well?
Because it might end up in the same spot in 4 years from the rewrite, maybe the issue is the page having too many responsibilities.
So it is an internal page that our employees use to generate most of our services. It certainly has way too many responsibilities and can definitely be split into multiple pages at this point. I think one person calculated over a million combinations of things you can do on that page.
There is what I used to know as 'Carmacks Law', but the Internet seems to have forgotten about it since the late 90's when I heard it, I must be getting old! I remember 'rewrite when you can, you will do a much better job the second time round without the baggage of old code', the nearest I can find is this:
brainyquote.com/quotes/john_carmac...
"One of the reasons microcomputers progressed so fast is people are willing to accept crashes. It's faster to build something and try it, even if it means you'll have to rebuild later... If you spent too much time building and massaging one vehicle, you don't learn anything"
Thanks Phil! I like building software prototypes (even those that are thrown away) so I definitely relate to that quote, and Carmack is a legendary engineer :D