All the code rewrites from the last several decades would like a word in return.
A bunch of those rewrites managed to miss critical things that were encoded in the existing logic in non-obvious ways. They broke a bunch of workflows that way.
A bunch of others went wildly over-budget and wound up getting shut down before they produced anything usable.
But surely the documentation will tell you all the use cases, and the expected inputs and outputs, right? Right? Oh, you don't have documentation like that? Yeah, then it's used in ways you don't know about, and your rewrite is likely to break them. (And that's true even if you do have such documentation, because it's incomplete.)
Rewrites are hard. They're deceptively hard. They look like they should be easy, and they very much are not.
"But this time we're going to use Rust!" Yeah, but the thing that makes rewrites so hard was never the language, so using Rust isn't going to actually fix it.
> Rewrites are hard. They're deceptively hard. They look like they should be easy, and they very much are not.
This is a major reason why so many financial/healthcare/insurance/government institutions still runs COBOL software on mainframes. Many times, you're looking at what is essentially a monolith (in many parts, but everything is connected in some way) that was 50+ years in the making.
Rewriting it is a huge and extremely expensive task, and had it not been because COBOL is considered a "bad language" by the young people, and thereby causing problems with recruitment, i'm guesssing the mainframe would be around for 100+ years to come.
As it is now, these companies are forced to migrate away from COBOL, and most companies in the financial sector would probably go for Java, which is posed to becomming the new COBOL.
If you start a career today as a young COBOL programmer, you will most likely have a high salary (for your career) for your entire work life.
The mainframe is certainly on the way out, but it's a big beast to move, and most "estimates" i hear from financial institutions is that they plan to migrate away in 10-30 years, and predicting what happens in 30 years is kinda pointless. Suffice to say that the Mainframe and COBOL is probably here for another 30-50 years.
I agree with your take and want to add that "we want less CVEs" and "we want meaningful rewrites" are not necessarily at odds with each other. We can have both.
I'll also note that efforts like rewriting a lot of UNIX userland in Rust also introduces the benefits of rewrites -- you have to think super hard if you want that obscure command-line switch that only works in X way if another switch has another value or it does the thing Y if two other switches have these other values. I forgot the examples but that's what happened there: people figured "we will not implement command switches X and Y" and lo and behold, people using those tools never even noticed, myself included.
So, rewrites have positives as well. And not everyone doing rewrites is clueless.
I didn't say that those who do rewrites are clueless. I said that rewrites are really hard - far harder than most people expect.
That weird switch behavior? I almost guarantee that someone, somwhere, some when depended on that behavior. Either they no longer use the switch behavior or they no longer use the tool, or they just don't use the rewritten version. But how do you know that? In the best case, the code would have a comment: "This code is to simulate Berkeley 3 behavior for users porting from..." But even that doesn't tell you whether anybody today still depends on it.
I mean, it could be a valid strategy to not rewrite weird behaviors - any of them - and see what breaks, and then only add the ones that are still needed. The upside is a much cleaner rewrite, with fewer (and, hopefully, better documented) weird behaviors. The downside is that you have to break stuff temporarily to find out. (Hopefully you break it in live staging rather than in production...)
>Rewrites are hard. They're deceptively hard. They look like they should be easy, and they very much are not.
well yeah, when we switch to an industry that values poaching over retention, you're going to have way too many cases of landmines whose knowledge was held by an employee who left or got laid off 4+ years ago. That makes them much harder than they need to be.
A close 2nd is indeed that documentation is the least valued business item out there. Employees who want to "grow" (financially) are practically encouraged to simply keep moving instead of ensuring future knowledge is spread.
A bunch of those rewrites managed to miss critical things that were encoded in the existing logic in non-obvious ways. They broke a bunch of workflows that way.
A bunch of others went wildly over-budget and wound up getting shut down before they produced anything usable.
But surely the documentation will tell you all the use cases, and the expected inputs and outputs, right? Right? Oh, you don't have documentation like that? Yeah, then it's used in ways you don't know about, and your rewrite is likely to break them. (And that's true even if you do have such documentation, because it's incomplete.)
Rewrites are hard. They're deceptively hard. They look like they should be easy, and they very much are not.
"But this time we're going to use Rust!" Yeah, but the thing that makes rewrites so hard was never the language, so using Rust isn't going to actually fix it.