Turns out brand new stuff doesn't always survive, and even if it does you don't know its tradeoffs & pain points yet.
Everything is perfect & bug-free when it has no product use.
Seen it many times, and seen the wreckage later.
Capable people know the constraints (and perhaps write good articles about them) and they know when to break those rules.
Good engineering is making the right compromises.
https://www.joelonsoftware.com/2002/04/11/our-net-strategy/
The idea isn't that you can't rewrite in a new language, it's that want to do bit by bit. Don't just to the big bang thing.
The engineering team in question had proposed to rewrite an old Java app with AWS Amolify and replace their Postgres database with Dynodb. The whole thing was then ducktaped with Lambdas and spread across multiple regions. They had not bothered writing a single line of test, never mind having any kind of build and deployment pipeline.. they didn’t even have basic error reporting.
After doing a deeper dive, we discovered that engineers didn’t have a local environment but only had access to staging, however they could easily connect to the production database from local by just updating environmental variables. It turns out that one of them had forgotten to switch it back after debugging something on production from his machine and had forgotten to switch it back.. he had a background cleanup job running in intervals which was wiping data..
It was a complete nightmare, the schema less nature of Dynamo made it harder to understand what is happening and the React UI would crash every 15 minutes due to an infinite loop.
The operation team had learned to use the Chrome console and clear the local storage manually before the window feeezes..
If you want to be successful in your career, when you are put in charge of a big new project, on a tight timeline, high management visibility, etc.. you dig into your existing tried & true toolkit to get the job done. There's so many other variables, why needlessly add more risk no one asked for?
But yes, I'm glad there are maniacs out there.. I just don't want to work with them.
Contrast this with frameworks that are created for the framework's own sake, hoping to attract its first application developers.
Haha. Yes. But when the c-suite is made up of top level management pushed out of the s&p 500, they always assume it’s their tried and true toolkit from another company. Believe me, it’s never the hammer the current engineering staff is holding. I’m slow clapping so hard for the business school graduates right now…
However, I can't count many companies I've seen decide to get into "the cloud" only to do lift-and-shifts and are now running their stack in slower and more expensive ways.
There's a reason this youtube video exists and it's because people get into hype and then are saddled with technical debt: https://www.youtube.com/watch?v=b2F-DItXtZs
Over the last decade I worked for a fintech that did analytics for the investment banking industry and between 2016-2020 the amount of people that were shocked we weren't trying to shove blockchain somewhere was surreal.
I’m pretty sure the majority of HN thinks that even hosting directly on EC2 is for NIH adventurers only.
It depends on what you mean by "multi-decade old app".
Excel is a multi-decade old app. Windows is a multi-decade old app.
They're both still being actively developed with a lot of new and cool features added though, and that keeps it fresh.
The multi-decade old app that hasn't been touched in 20 years? It need a rewrite. And yesterday.
I suspect though, that is not what you meant.
And we need to stop all new feature work on Excel since its legacy, so give me 80% of the dev team to do above. Oh btw, they don't know the alphabet soup of stuff I decided to use, so we will also start firing them as well, as I need to hire for these special skills.
Eventually styles will change and you will have to redo the UI. This will happen much more often than the above. Your program may look very different but if you have a good architecture this is a superficial change. It may still be expensive, but none of your core logic changes. Normally you keep the old and new UI running side by side (depending on the type of program may be different builds, other times it is just a front end) until you trust the new one. (depending on details it may be an all at once switch or one screen/widget at a time)
What does that suppose to mean
To frame your argument, TIOBE ranks COBOL as the 19th most popular language, ahead of Ruby.
It's beyond useless.
This is a better list, and cobol is not even part of the top 20, while Ruby is at 9th place: https://redmonk.com/sogrady/2024/03/08/language-rankings-1-2...
https://www.rocketsoftware.com/en-us/products/cobol/visual-c...
Anyway, as soon as LLM can reliably produce executables directly, languages will lose their value, it is the new Assembly to high level evolution.
It's like I'm sitting in a meeting.
Depending on the project, it might actually be the only sane option if you're still required to make significant changes to the application and features have be be continuously added - and the project has already become so full of technical debt that even minor changes such as mapping an additional attribute can take days.
As an easily explained example for such: I remember an angular fronted I had to maintain a while ago.
The full scope of the application was to display a dynamic form via multiple inputs and interdependent on the selected choices of the available form (so if question 1 had answer a, question 2+3 had to be answered etc).
While I wouldn't call such a behavior completely trivial, on a difficulty line it was definitely towards the easy end - but the actual code was so poorly written that any tiny change always led to regressions.
It was quite silly that we weren't allowed to invest the ~2 weeks to recreate it
Another example that comes to mind is a backend rewrite of a multi million PHP API to a Java backend. They just put the new Java backend in front of the old API and proxied through while they implemented the new routes. While it took over 2 years in total, it went relatively well.
But yeah, lots of Greenfield rewrites end in disaster. I give you that!
You are describing a web form.
If something is a 2 week rewrite, write it in BASIC, write it in a language you invented, whatever, have fun.
Their next example was exactly what you asked for, 2 years rewrite.
Bonus points from me because they didn't wait for the whole rewrite to be done, and instead started using the new project by replacing only parts of the original one.
Building the bridge between the old & new, replacing piecemeal, and maintaining service to users the whole time.
I'm convinced on hindsight that we could have just refactored in place and been just as well off. Sure there would be some code that is still the ugly mess that made us jump to the big rewrite in the first place. However we would have had working code all along to ship. Much more importantly, we fixed a lot of problems in the rewrite - but we introduced other problems that we didn't anticipate at the same time, and fixing them means either another rewrite, or do an in-place refactor. The in-place refactor gives one advantage - if whatever new hotness we choose doesn't work in the real world we will discover before it becomes a difficult to change architecture decision.
The only time it really makes sense to do a rewrite, is when either a new architecture/technology is going to be used that will impact team competency, or the team's competency has improved significantly but is being held back by the legacy application.
In both of those situations though, you could and should absolutely cut the application into pieces, and rewrite in place, in digestible, testable chunks.
The only time it makes sense to do a wholesale greenfield rewrite, is political. For example, maybe you have a one-time funding opportunity, with a hard deadline (rewrite before acquisition or ipo, etc).
We have also improved a lot as an industry. The rewrite was started in C++98 because C++11 was still a couple years away. Today C++23 has a lot of nice things, but some of the core APIs still are C++98 (though less every year) because that is all we had the ability to use. And of course rust wasn't an option back then, but if we were to start today would get a serious look.
In hindsight, cleaning up that Perl and C++ code, even where both languages stand today, would have been a much better outcome, than everything else that was produced out of that rewrite.
But hey, we all got to improve our CVs during that rewrite and got assigned better roles at the end, so who cares. /s