It's very rare for a rewrite to make sense unless the underlying stuff has so fundamentally changed you don't really have a choice. (For example, DOS to Windows. You have to scrap your UI completely.)
It's very rare for a rewrite to make sense unless the underlying stuff has so fundamentally changed you don't really have a choice. (For example, DOS to Windows. You have to scrap your UI completely.)
I once was involved in a complete rewrite in a new language that ended up saving the company -- so those do happen, empirically.
That was an unusual scenario, however; the previous iteration of the product had major issues, buggy and costly to maintain, and the language change was in part for the purpose of repointing the hiring pipeline toward a different kind of profile. Such special circumstances aside, I'm with you on recommending against rewrites. Much as I'm often tempted.
Indeed, and the perhaps canonical article on "don't rewrite" from 2000: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
I'm working on such a re-write / learning process right now because underlying stuff has fundamentally changed and it was (slightly) long past time to make the move. Of course, we're still going things incrementally and slowly and making effort to keep older tech running.
For some tech choices there was just one clear path from where we are to where we need to go. But for others, the overriding decision was more often than not that some team member had familiarity with the technology. Certainly not the only criteria but enough to tip the scales if it came to that.
This is true, but the article is not about rewriting.
VB.Net winforms app from 2005?