How often have you done a huge refactor/migration and ended up with something worse than before?
Posted by iMac_Hunt@reddit | ExperiencedDevs | View on Reddit | 185 comments
Our CTO convinced us to move our .NET applications to Node/nestJS a few years ago. While it’s not all bad, the benefits have simply down to better architecture choices and they could have easily been done in .NET. The number of headaches that NestJS has caused though is huge. I respected the CTO a lot but to this day I think he just had a huge anti-Microsoft bias he couldn’t get over.
I’m curious how common this is across the industry, especially if there are any real disaster migration stories.
mint3d@reddit
My CTO made my write a data intensive app, crunching thousands of rows from a mongodb database on front-end in react. It used to take minutes for data to render.
He thought this saved budget on compute. The project died two years later.
grimcuzzer@reddit
Did he come from a Salesforce background? Because they often encourage delegating computations to client side.
Far_Swordfish5729@reddit
That is a straight up junior dev teachable moment. I would love to whiteboard for him exactly how and why he’s wrong from a performance, compite cost of serialization, egress, and security perspective.
The hard numbers I go to are the IO bound latency cost of distance from the cpu: 1 cycle for registers, 5 for cpu cache, 100 for ram, 100k for attached disk (hence why the OS aggressively pages to RAM), 10M-1B for network/internet under low latency conditions. You don’t bulk ship data across networks if it’s sitting in database server ram cache already and you just need the calculation output…ever.
horserino@reddit
Devil's advocate: It's not by definition a bad idea to push compute to clients. If some compute is done by the server, it means the server has to be able to handle computing that thing for some N number of active clients. Things add up quickly.
A client only needs to compute their own thing, and you don't pay for that compute which is good. So pushing compute to the client can make sense in some contexts.
A dumb analogy: Think of an online game. The server is not gonna be computing the visible scene from the perspective of every single player. Instead (an approach) is for the server to keep track of the current world state and compute (or validate) the next world state and send the minimum info changes to clients. Clients can compute their visible scene themselves.
Of course, it depends on the context and application. Minutes to load a page is bad UX. But unlike other commenters, I'm not shocked by the idea itself, of pushing some compute to clients.
mint3d@reddit
These were MOM and YOY reports. Once calculated and stored in a collection, it could have been used for the entire month.
horserino@reddit
Indeed, I struggle to see how it could be a good idea in that usecase 😅
horserino@reddit
Although arguably, you have videogame streaming nowadays, where the hard graphic compute is indeed done server side. I really wonder what the finances of that are.
Saetia_V_Neck@reddit
MongoDB is webscale though???
mint3d@reddit
I could seriously have take some inspiration from that when writing my resignation letter.
callimonk@reddit
me, a front end dev who has worked in react, nodejs, and mongodb:
jesus christ that's so many bad ideas.
CpnStumpy@reddit
Like all of them. None were left, I guess the CTO was a completionist
callimonk@reddit
Definitely an achievement of sorts..
zabby39103@reddit
Lmao, that's insane. Compute is so cheap now. Okay technically possible, but I'd love to see a "real world" not made up case that makes sense.
BERLAUR@reddit
I don't mean to be critical but react should be able to render a (few) thousand rows without major issues, shouldn't it?. Modern JS usually has pretty acceptable performance.
For my understanding (genuinely curious) what exactly was the bottleneck?
avoid_pro@reddit
React can handle it, but 2k rows are like 20k nodes at minimum. So change their place, changing data, performing any visual changes will eventually increases nodes count and very possibly memory usage. Also, abusing useCallback and useMemo will make things even worse.
robby_arctor@reddit
If that was the issue, surely virtualization could have helped.
mint3d@reddit
React wasn't the issue, crunching the numbers were.
PoopsCodeAllTheTime@reddit
CTOs doing this and I'm still unemployed, side love this "meritocracy" (not).
mint3d@reddit
The irony
vvf@reddit
This breaks almost every “rule” I can think of…impressive
belkh@reddit
Crunching thousands of rows in the frontend isn't extremely bad, as long as you know your clients have good internet (data analysts in the office with gigabit internet), absolutely horrible for customer facing products though
New_Enthusiasm9053@reddit
Only if you also know they have good computers lol. Waiting minutes sucks no matter who you are.
callimonk@reddit
yeah, exactly - I really hate how many business decisions I've seen that want to run data on the front end side. it's been advised against for decades because even if you can guarantee the client will have a great setup, its just.. bad architecture and imo an excuse for bad practices.
(I get what u/belkh is saying and I've definitely had to rail against these decisions even in those situations, pointing out that its still a time loss on the client end)
belkh@reddit
Yea there's a big gap between good and not extremely bad, sometimes you need something quick and dirty and a duckdb frontend might be all you need to do some ad query some data off s3/postgres, which would have otherwise had you deploy some spark or trino cluster
callimonk@reddit
Totally! In the case of what's described though of hundreds of thousands or whatever lines being crunched.. oh god, that gives me psychic damage.
PhilosopherNo2640@reddit
My team is taking a java monolith (,java backend running on websphere with jsp pages) to distributed microservices and micro front ends ( spring boot services, angular front ends).
What prompted this was a request from the business that my team needs to support more simultaneous feature development than the monolith supports. It's a reasonable request. BUT...
One issue with the monolith is complexity. Making this app distributed will multiply the complexity x 10. My team does not have enough senior level talent for this. For some reason I seem to one of the few people expressing this concern.
My .02 is that the distributed app will take twice as many people to maintain as the monolith, for the same features.
It does not seem like a good idea to me . But it seems that no one cares about my perspective. :)
HotTemperature5850@reddit
Different tech stack at my company but same project. We successfully moved a huge chunk of it to microservices. Now the deploy pipeline for certain parts of the product is much faster, which is one of the things leadership really wanted from this project, but actually modifying the new microservices takes 10x as long because the architecture is overcomplicated and you have to work in six different repos to add a new API endpoint. Debugging is a nightmare because we didn't have the time and resources to implement a decent distributed tracing solution while we were scrambling to get to feature parity with the legacy system on a very tight deadline.
I miss working on the old PHP monolith on a daily basis. It feels like an entire year of my life was wasted on making something worse while being incredibly stressed out in the process and I am now on the verge of quitting this career entirely.
PhilosopherNo2640@reddit
You are correct. We work on the same project.
putin_my_ass@reddit
Most accurate summary of what it feels like to be a software developer.
kuncol02@reddit
"Everything as micro services" is second stupidest trend I saw in IT in my carer.
I saw app that has expected user count in few hundreds max per installation (not even few hundreds concurrent requests but few hundreds people who will use it at all) without any chances to be scaled higher designed as micro services. Not even taking into account that it's web app that is required to work offline and may require gigabytes of data that need to be kept locally.
Less-Fondant-3054@reddit
Oh no, the stupidest was what came after microservices - IAC. No more services, all business logic contained in the actual configuration of your cloud infrastructure and "cloud functions" that were literally just one-method microservices that were written in cloud config language instead of application code. It was a natural outgrowth of the microservices idea but it was just taking the problem parts of microservices and dialing them up to 100. Fortunately it seems to have been a short-lived trend.
kuncol02@reddit
I guess I totally missed that trend, but to be fair I'm one of dinosaurs that mostly work on desktop applications with native ui and I will leave industry and become coal burner before anyone will force me to write single line of javascript.
hippydipster@reddit
I'm jelly. I've worked on many a desktop app (including currently), but it's never been the primary focus. I like it so much more than server crap.
Less-Fondant-3054@reddit
It was fairly short-lived, fortunately. Mostly because businesses love to change cloud providers in order to chase the best price and IAC is very vendor-locked.
kuncol02@reddit
I feel like saying "very vendor-locked" is understatement in this case.
Less-Fondant-3054@reddit
It sounds like the issue is that your management/architects are cargo-culting. They're demanding very rigid adherence to ideal microservice architecture despite it not being a good fit and that's a sign that they don't actually understand microservices and are just viewing them as a magic fix. Your use case is probably best served with a small group of micro-monoliths, a very common pattern to be found today.
SolarNachoes@reddit
That should have been obvious up front.
You can modularize a monolith.
Euphoric-Usual-5169@reddit
I never get it why people think they can do microservices right if they can't manage to write decent libraries.
PhilosopherNo2640@reddit
Haha, you just described my team.
CalmLake999@reddit
Microsoft did a lot of damage to the tech industry during the 2000s and early 2010s. I was a huge victim of that (lost millions).
They are better now, but many can't forget that, and cannot trust large tech companies again.
dauchande@reddit
Probably because people have redefined what the word, ‘refactor’ means. It used to mean to make a change that didn’t affect behavior, but now it seems to be a synonym for restructure/rewrite.
adyst_@reddit
I'm in the middle of one and I'm considering quitting over it
HotTemperature5850@reddit
I spent the past year and a half working on one and it has pushed me to my breaking point. I've considered starting an OnlyFans so I never have to work a software-related job again.
Significant-Leg1070@reddit
What are you moving from and moving to ?
adyst_@reddit
The tech stack is too specific to disclose anonymously, but it's a web application that we are migrating from a legacy web tech into a mobile-specific framework.
bluetrust@reddit
Sounds like Flutter. I was playing with that a couple weeks ago and wondered who would be using it for the web.
Significant-Leg1070@reddit
Ouch. Yeah we canned a .net Maui migration last year and will just refactor the Java 8 app into modern Java and spring. Management thought they wanted a native desktop framework with mobile flexibility but they were wrong
0vl223@reddit
That sounds like a nightmare. If they really need a native app then keeping windows, android and apple code in sync is a huge hassle. And if they don't need an app java backend and a website is a way easier migration to cover mobile devices.
PhilosopherNo2640@reddit
Im sympathetic. See my top level comment. Ive considered quitting for similar trasons.
Euphoric-Neon-2054@reddit
good news: this is a natural portion of the migration cycle
neutral news: it is not an indicator of success or failure
bad news: feels bad man
Windyvale@reddit
Moving from .NET to node is…a choice.
rk06@reddit
and a stupid choice at that.. NET is extremely fast, node is not.
arcticmaxi@reddit
Agreed, i've found node to be extremely janky and brittle under any form of stress, and the nature of the language seems to promote overlooking code structure and strict definitions
It's more common to see migrations away from nodejs instead of towards it
vezaynk@reddit
How is it brittle?
callimonk@reddit
i love nodejs, and i support this comment whole-heartedly. its just.. not really designed IMO for the things .NET handles
zabby39103@reddit
Everyone has their pet favorite stacks, you gotta check that ego at the door and look at what you actually have and your team's skills. It's not like there's a shortage of .NET devs.
iMac_Hunt@reddit (OP)
To this day I still find it strange, I thought he otherwise made some strong architectural decisions. I think .NET has come a long way since .Net Framework days, and he didn’t seem to have a very old fashioned view of the ecosystem
0_one_2_three_4@reddit
Most of it boils down to terrible cloud architecture decisions being blamed on some outdated advice that .NET isn't performant.
CTO probably got all hyped about seeing node mentioned in a bunch of startups and thought it was a magic silver bullet to cure all your problems. Once your migration is complete you'll probably realize you have the same problems and they'll be even worse to untangle.
I've worked with .Net for a long time. 99% of the problems are because of bad cloud architecture, hellish over-abstraction, terrible EF query optimization, or just flat out bad database design.
bluemage-loves-tacos@reddit
I don't think it's got much to do with where .NET was when he last looked at it, and more to do with how he doesn't want to have that eco system because of some bias.
I don't like .NET either, but I'd rather quit my job than move from that to node of all things.
PoopsCodeAllTheTime@reddit
I'm a node user, it does get the job done in similar quality. The difference is in the flexibility when writing code. I prefer the higher flexibility of node when I'm the one settling the patterns, but not when someone else had fun with the codebase before me.
Leather-Rice5025@reddit
Was going to comment the same thing... I'd take the .NET/C# ecosystem over Node's ANY day for an established system.
bonnydoe@reddit
I think you should ask devs at banks ;)
03263@reddit
I've done big refactors but they end up better than before. That's kind of my niche, legacy modernization. However I don't change the language it's written in, nor the framework unless the framework used is too outdated or no longer maintained.
I really wouldn't ever pick Node, JS or TS for any rebuild though, they do not lend themselves to clean architecture for large systems.
never-starting-over@reddit
Why doesn't TS lend itself to clean architecture in large systems? What do you define as a large system in this case?
I'm surprised to hear this. How come this is about TS and not the way some people have implemented things that just needed to be refactored eventually?
03263@reddit
Mainly the tooling and module system are not very nice. TS is just JS with strict typing, it still suffers from all the JS architectural issues. There's no globally accepted/enforced convention for organizing file structure and naming things, each project has its own conventions.
Wonderful-Habit-139@reddit
No, TS is a statically typed programming language that has a very powerful type system. It’s leagues ahead of writing JS.
never-starting-over@reddit
Coming from developing mainly with Golang, TypeScript and Python, I'm not familiar with what the other options are there. Are you saying this in comparison specifically to Ruby on Rails, Java's what-nots (I'm not familiar with Java), etc?
I'm still not seeing what specifically is the problem. What do you mean with architectural issues? What kind of guardrails/intended limitations do you think should be in place that other languages that lend themselves to large systems have?
I'm not even trying to argue or anything, I genuinely just don't get it yet
jfinch3@reddit
Imo TS doesn’t have anywhere near the depth of features you have in something like C# or Java. Especially wrt to performance optimization I feel like there’s real limits to what you can do if you workloads which aren’t IO bound.
TS is a big improvement over vanilla JS for a backend project, and it’s great you can do that if you already have people who know TS, but I’ve never reach for it if given a totally green field.
Personally speaking, not being able to have true run time control flow based on the type of an object is huge. In TS you have to hack around that and even then that requires knowledge and buy-in from a team.
Wonderful-Habit-139@reddit
TypeScript has a more powerful type system than C# or Java.
roynoise@reddit
You can write Clean Code and implement Clean Architecture just fine with JS. Just be a good/responsible programmer.
Wonderful-Habit-139@reddit
Doesn’t work in a team. And doesn’t work for your future self.
Just learn how to use the type system to your advantage and you get to encode a lot of invariants at compile time instead of letting edge cases slip through the cracks.
edwinjm@reddit
It’s not 2005 anymore. JavaScript and TypeScript are fully capable for large, complex systems.
studmoobs@reddit
doesn't mean it's a good idea
03263@reddit
JS no way, it's too dynamic, can't trust anything without extremely defensive coding practices. TS fixes a lot of that.
csanon212@reddit
I let a mid level dev refactor an API project into a more modern framework.
Worked well 99% but its core logic used some currying/reduce magic that no one understood. When this guy left, the service toppled over and I had to debug it line by line over 4 hours while there was an active production fire.
We swapped in the old version 1 week later at very senior management decree.
FortuneIIIPick@reddit
They had you move from .NET to Node? Seems like Java/Spring Boot would have been better than Node.
ButWhatIfPotato@reddit
Honestly never, because from my experience it goes something like this:
Less-Fondant-3054@reddit
You forgot the step between 3 and 4: stakeholders refuse to accept that forgotten and unused functionality has to be left behind and delay the project repeatedly to ensure that ALL functionality, no matter how moribund, gets included in the rewrite. That causes dev to crawl to a halt and that's why no progress happens.=
yetiflask@reddit
So motherfucking yes. I went thru this, and had to plead to product that they should use this opportunity to simplify, and they dug their heels and we removed one cancer to create another - just in a modern language.
TomarikFTW@reddit
This!
Had a refactor to a new framework. Old app generated a report.
New app needed to generate a report. I just put a button with a link with Wikipedia.
Took them 2 years to realize!
Asked them to submit a ticket. No ticket. Must have been a really important report 🙄
SnakeSeer@reddit
Or they refuse the ability for a rewrite to introduce new functionality. The fights we have had over being able to to introduce new functionality because we no longer have technical constraints...no, apparently we must replicate the dysfunctional pattern of the old system because that's how the old system does things and the business people can't handle change at all.
Agent7619@reddit
But customer XYZ uses that feature.
Customer XYZ uses competitor ABC?
Yeah, but they might switch.
We added that feature 10 years ago when you tried to get their business and they told you to fuck off.
Infinite_Maximum_820@reddit
I finished one but then decided not to put in prod.
Was a 30k line build system written purely in make doing sub process to Python 2.4 building our repo mono for 20 years
I just thought about all the possible bugs … and it kind of worked, after the rewrite I actually understood it well enough to support it
Existing_Priority172@reddit
We made the move from node to java. This has reduced number of pods needed in prod and increased the number of oomkills and other mysterious issues in my opsgenie.
butler_me_judith@reddit
That nodejs refactor is wild. The best benefit is it is easier to higher for ts devs.
NestJS is what really throws me, we tested it and preferred to just stick to our own abstractions. The opinionination is a bit overkill for my taste
HyperDanon@reddit
Big refactors and migrations are common. That's why I prefer to work in smaller steps. Of course, still 50% of my changes will land me in a worse place, so i'll revert those. If the resulting refactor is cool, I'll leave it in. Then repeat. Do that enough, your system gradually improves. Of course you can only do that with reversible changes.
Rena-@reddit
I’m currently leading a refactor of a high-volume telemetry service from Java Spring to Rust. It’s been a tough but cool effort. Not just a language rewrite, but a full architectural overhaul. We’ve had to rethink data flow, concurrency, and performance from the ground up.
So far, it’s reinforced for me that most of the real wins come from architectural clarity, not the language itself. The tech stack helps, sure, but solid design decisions and understanding the system’s pain points make the biggest difference.
chocolateAbuser@reddit
i got one of those stories
services i work on were make by an ex-coworker as uni project which got transformed in the current production system
when it got to v8 for next release we wanted to leave .net framework and rewrite the service in .net core, which is a pro
but then he started designing the architecture, and he didn't really knew how to manage a project so there is almost no feature isolation, he intentionally put everything strictly together, dtos are essentially db models, there's automapper everywhere with logics in the profiles, event queue bus used badly, and ef core used even worse... almost every decision taken was the opposite of what you should do
then he left
and now i'm trying to rewrite this in a more decent way... while adding features, while maintaining retrocompatibility, while doing 999 other things
tomqmasters@reddit
Unfortunately the bigger issue is that sometimes I don't know if what I've done made things better or worse. The infrastructure needed to keep track of that is as cumbersome as the code base itself.
AppropriateSpell5405@reddit
Most CTOs have failed upwards and are just comically inept.
alanbdee@reddit
I have to be mentally behind everything I do or is ends up sucking. If you don't see a real benefit of switching from .NET to nestjs then it's going to end up sucking. He could be thinking that "node developers" are cheaper but I'd argue that's not a good thing.
iMac_Hunt@reddit (OP)
Well I was pretty agnostic to the decision at the start and stayed open minded. It’s more than retrospectively I feel it caused more problems than it was worth.
And yes your right, he did argue it will be better for hiring, however we haven’t even had the budget to hire since the change
alanbdee@reddit
I think it looks easier because there's more candidates but more of them are crap. So it's harder to filter out the good from the weekend bootcamp, AI wielding "devs"
praetor-@reddit
As someone who has worked in both stacks extensively I can assure you the opposite is true
horserino@reddit
Easier to find good JS devs rather than .Net devs?
callimonk@reddit
yeah, Vercel iirc has had a huge push for AI vibecode.. which, well, we all know how that's being marketed.
ESGPandepic@reddit
Microsoft is also doing a big push for copilot usage on PRs to the dotnet codebase though, which hasn't been going well
callimonk@reddit
Oh yeah, I've seen some of those. Love to watch the world burn..
alanbdee@reddit
Its very important to know and expect that it'll get things wrong. But it'll be roughly 80% correct. It only gives a starting point that you then refine. This has been my overall AI experience; let AI take a stab at it, then fix what it got wrong.
callimonk@reddit
Yep, pretty much this. I'm super frustrated at work seeing non-devs tackling our work and then I have to fix it pretty much every time.. sigh. It can't follow basic design patterns ffs, and patterns are what it's usually good at.
alanbdee@reddit
This is also why I don't think we're seeing a huge gain in time. Sure, AI can hammer out parts quickly but then it takes me just as long to track down what it got wrong, or alter it to match other parts of the site to be consistent architecturally.
C0git0@reddit
Generally moving to typescript on the backend isn’t to make the codebase better, it’s to open the hiring pipeline to more devs.
Sparaucchio@reddit
But is it really? Typescript is so much more complicated than most other mainstream backend languages, due to its type-system and lack of types at runtime. Not to mention issues when the compiler blows up and the IDE takes minutes for an auto-complete suggestion...
praetor-@reddit
More people that have startup experience and/or want to work at a startup and/or work/ed at tech companies are interested in working in TS than .NET
BarfingOnMyFace@reddit
Not worse, just incomplete in its own way. Many things get improved upon, but not enough time is allocated to get past 90% before people start bolting on clients and shipping to prod. Improvements do happen, but dreams are smashed along the way and you end up with some mockingly ugly, stunted, buggy version looking back at you in the mirror instead.
Accurate_Ball_6402@reddit
The problem is nestJS wants to be like .NET so badly but it might take them another 1-2 decades to achieve that if ever.
deltanine99@reddit
Your cto is an idiot.
iscottjs@reddit
What’s wrong with nest? It’s been on my radar as possible candidates for future tech stacks but never pulled the trigger.
Spare_Message_3607@reddit
Crazy behaviour, I think Java was the move if they were looking for the Anti Microsoft. Just a reminder Typescript is also Microsoft's language. JS is the language perfect to move off of, not the one you migrate into...
PythonN00b101@reddit
I’m not a lead by any means but did they propose it as a spike or discovery? I’ve done it, Started with the smallest service, observed the outcome, looked at metrics, what worked well, what didn’t…and then I decided to scrap it because it wasn’t worth the headache lol.
Did he just unilaterally decide to rewrite without any of the opinions of the seniors?….because that shit is wild.
mrfoozywooj@reddit
I have seen it.
We proposed a re-platform / rewrite of a legacy app that was managed in an extremely dated way by devs who would edit files/the db in prod by hand and had only recently started using git instead of copy/paste files.
The plan was solid until they gave it to those very same devs to implement, now its a rube-goldberg monstrosity thats crazy expensive to maintain.
twnbay76@reddit
Your CTO is a total joke and I'd get out as soon as humanly possible lol. Then again, my CTO is pretty horrible as well. But he's more of a does nothing horrible while some ppl under him do cool things that doesn't involve migrating langs because someone said so lol
alkxlinxe@reddit
What didn’t you like about Nestjs (as someone who uses it frequently).
jamestakesflight@reddit
Very famous post about Netscape (I may be dating myself) and an attempt to replatform there. The title says it all . . .
Things You Should Never Do, Part I
Less-Fondant-3054@reddit
Never. The refactor projects always wind up killed off when they're showing that they can't keep up or just because management never managed to manage their own expectations.
Also you shouldn't respect your CTO. .NET is a backend language, JS frameworks are frontend. No matter what frontend kiddies like to pretend you cannot do backend work in frontend languages. Not if you want any kind of performance. If someone got to CTO level and still doesn't get that they're not respectable.
Chezzymann@reddit
I mean it really depends on the type of work you're doing. I've worked on projects with millions of users that scaled just fine in node. In my experience, its usually the database or the high level architecture that's the bottleneck, not the language used.
gymell@reddit
Disagree. .NET is not a language, it's a backend platform. Node.js is also a backend platform that is widely used and performs quite well. There are several frameworks that can be used with it. I'm not saying that what the OP is describing is a particularly good choice by the CTO, but it's not because of the technology. It's because the choice was made due to his personal biases rather than for sound technical reasons.
bolacha_de_polvilho@reddit
I've seen a large refactoring from one framework to another one in the same language go alright. But it was a somewhat small project and being the same language meant most of the core logic is unchanged. And it had to be done since the old framework was being deprecated.
Changing from one language to another is a full rewrite, not a refactor or a migration, there's no way that is ever gonna go well for a decently sized project. Maybe if you're moving from an esoteric/outdated language nobody uses to a market standard one the temporary pains might justified (like going from cobol to java), but to rewrite from dotnet to js is insane for a backend (specially since that's a big downgrade if you ask me lol).
Sounds like the guy just had a personal preference of stack and forced it onto everyone with no objective reasoning whatsoever.
LondonPilot@reddit
Yeah, I agree.
I did a full re-write of a system from OutSystems (you’ll probably have to google that, so I guess it counts as esoteric) to C#/.Net. Took well over a year, was a massive pain, would not recommend. But it was necessary - apart from OutSystems being esoteric, the old software was extremely badly written (I’m talking no design whatsoever, every database field being a string even if it held numeric data, no use of identity columns or similar in the database - just grab the highest number and add one to it, which works fine until you have two users, that kind of thing). And the company had contractual issues with OutSystems. I learned a lot on that project!
So yes, sometimes full re-writes are needed. But they’ll never not be painful.
Franks2000inchTV@reddit
If you're moving from android/iOS to react native you can do it with a ship-of-theseus approach, replacing one view at a time.
PoopsCodeAllTheTime@reddit
Objective reasoning: he likes it better, which makes the job easier for the key employee that rubs the project. :)
shelledroot@reddit
I was going to write a comment but this already covers everything I wanted to say. D:
In general you want to keep refactor/migrations as simple as possible, even the most straightforward one will incur some pain, the more complexity introduced the more pain generally speaking.
Early-Surround7413@reddit
Isn't the answer 100% for everyone? LOL
boreddissident@reddit
I thought node was what you refactored away from hahah.
AppointmentDry9660@reddit
That would make more sense
boreddissident@reddit
I think the whole industry needs to look at the big trend of Angular / node + React / etc full stack client-server JS web apps and then look at traditional PHP code bases from 2010 and ask ourselves if we really made anything any better. Are we shipping faster?
Less-Fondant-3054@reddit
Most websites are far less performant than they were back then. That's for damned sure. The network speed is orders of magnitude faster but the rendering is so slow that the modern internet creeps and crawls.
CamelCavalry@reddit
I've done very little FE. How much of this do you think is the Node + JS being worse/slower and how much do you think it's the whole ecosystem of JS, npm, etc. making it really easy to unwittingly create really, really bloated web pages? Or are we adding very heavy low-value "features" that we just didn't do back then?
Skullclownlol@reddit
JS existed back then too, and node is fast. 99,999999999% the latter.
Less-Fondant-3054@reddit
It's mostly the latter two Node + JS on its own is plenty quick. The problem is that nobody uses them that way. The pack it with bloat and then use that bloat to implement low or negative value "features" to the site.
callimonk@reddit
It's only getting worse with AI code that ignores standards and introduces layers upon layers of enshittification. All these posts scared of FEE dying, meanwhile I'm having to fix vibe coded bullshit that's slower than the code I wrote 10 years ago because it can't follow basic practices.
callimonk@reddit
as an ex PHP 4 dev (who did get to do a little, but not much, in PHP 5).. I'll take node over it any day.
however, if I have other options, I will absolutely take them over node almost any time. It's fast for me to spin up a node stack and whatever, but it's just not the right tool for most app backends.
rayreaper@reddit
PHP 4 is nearly 25 years old, it's came leaps and bounds since then.
callimonk@reddit
Yeha, I put in the version numbers so it was clear that the suffering came from working in a place that, for reasons, couldn't update haha. I'm sure it has - 5.1 was a massive leap above 4, but I know I'm a bit biased against PHP because of that early job.
AppointmentDry9660@reddit
We are creating prototypes faster but enterprise grade problems will show their ugly ass at some level of scale
boreddissident@reddit
Well prototyping is now the job of the most energetic person on the product team who teaches themselves vibe coding. Maybe we won't need that kind of thing any more.
Next web app I build is going to be pure SSR in a backend language and JavaScript will just be for what it was always meant for. I'm done with the nonsense.
AppointmentDry9660@reddit
My first shop used NOLOH. Unfortunately it was pretty slow.. maybe there are better alternatives today
boreddissident@reddit
Laravel is modern and perfectly fine. I worked a Laravel contract during the pandemic for a while.
I certainly don't love PHP, but I don't think the way many websites are built now has made anything any easier or cheaper.
orbitur@reddit
This is a common story on the mobile side, many companies continue to attempt React Native in the hopes of saving dollars.
This may work fine for small teams or small apps, but at scale it’s a miserable transition. Shopify, or the CEO at least, is very stubborn, so they spent 6 years and billions of dollars committing to React Native, and now they have mountains of infrastructure they need to maintain to keep RN viable. They have been just as committed to a ruby, spending billions and years on performance and optimization. Admirable, and fun work if you’re rich enough to keep hacking away at it, but the benefits of “lower cost” are just not there, and maintenance costs continue to rise as Android and iOS continue to iterate.
LargeSale8354@reddit
In my experience a large migration ends up wiyh 80% of what you had before. The next few years fill in the missing 20% only for the next rewrite to materialize.
jonnycoder4005@reddit
Javascript = haha
Javascript on the backend = haahbhaahahahhaahabbbbhahahahaah
EngineerFeverDreams@reddit
I don't know all the details but your CTO is likely terrible at their job. Maybe a founder that is there too long?
The only reason to do that migration would be that you can't find employees. In which case it's a lot easier to pay better than it is to go through that replatforming.
iMac_Hunt@reddit (OP)
To be fair it’s a startup and everyone was in agreement that everything needed full re-write eventually - it was all written by juniors who had no idea what they were doing.
AromaticStrike9@reddit
Most startups hit this stage. They are more often than not wrong. Improving while you build on the existing thing is almost always possible, and almost always the right choice for a startup. It's way too risky to spend time and money on a re-write unless you're absolutely rolling in funds and time.
Far_Function7560@reddit
Yeah, I've seen too many of these full rewrite projects go off the rails, I'm convinced at this point that reworking and refactoring the existing app will be the better option more often than not. Engineers just are too in love with the idea of starting with a clean slate with the shiniest tech and think everything will go better in the next attempt.
iMac_Hunt@reddit (OP)
Perhaps I should what we were dealing with:
A fully stateful application that stored crazy things in session state, including unnecessary objects and even base64-encoded images.
Controller files with over 50,000 lines - zero abstraction of course
No tests whatsoever
Some Data stored as huge nested JSON blobs inside SQL Server, where relational tables clearly should’ve been used
Separate controllers for mobile users, containing the exact same copied code. To this day the reason remains a mystery.
Database columns stored as strings that were actually numbers.
Cryptically named database columns. Apparently as a ‘security measure in case the database got hacked.’
EngineerFeverDreams@reddit
What should we do with this large, cryptically named codebase with no tests? Let's rewrite it entirely!
https://world.hey.com/dhh/building-basecamp-4-405a347f
A smart, experienced CTO knows you don't do this.
Maybe you're working in COBOL and can't find anyone to maintain. You pay a few gray haired engineers very well to stick around and help rewrite it. Not when we're talking about a modern language where you can easily find people to work on your platform.
Let me guess, you're also building on top of the old platform at the same time. So you're building a ship while sailing an old ship that you have to patch. Both ships have to look the same in the end.
Mr_Loopers@reddit
This sounds way too complicated to rewrite from scratch. (This cannot be classified as a refactor).
Start with tests, and then address these points individually, and carefully. Maintain redundant those legacy huge nested JSON blobs, and databases, until they've become irrelevant so you never need to break backwards, and forwards compatibility.
Once you break compatibility, your rewrite is destined to fail, IMO.
AppointmentDry9660@reddit
Every software business has to do something with their legacy code at some point... I don't work in .net but I don't think I would make this choice
Recently I created inheritance based code for an 8 year old project, so the legacy parts could still exist (as sub classes because they have parts we only need for very specific instances) so we could have more flexibility where needed. If you write unit tests, doing big changes like this ensure that you are successful even if there are big changes
EngineerFeverDreams@reddit
😆 yup, figured as much. Bike shedding en masse.
damnburglar@reddit
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
PaulPhxAz@reddit
Very common. I've rarely seen an Upper Management type come in and not want to put their "Stamp" on projects. Either criticize it heavily or say they needed a re-write in X,Y,Z technology or whatever.
The two factors I usually see are: Immaturity and Insecurity.
It's easy to tear down people and projects, it's hard to build.
engineered_academic@reddit
Moved a perfectly functioning app from Ruby on Rails to Clojure because the lead dev wanted some resume driven development. The RoR app could have been optimized and was rock-solid. Nobody understood Clojure well enough to understand the problems that would crop up years later. Learned a lesson about technology standardization that day.
4tma@reddit
Clojure is a beautiful language but I wouldn’t migrate an existing system to it unless there are glaring issues solved by this and the whole team was onboard.
4tma@reddit
Positive outcome: we migrated from Flutter + Django to just Phoenix with LiveView. We are soaring and have 0 regrets.
newprince@reddit
It depends sometimes on expectations. Sometimes people want to be assured that it will 100% do everything it used to, just better and faster, and that's unrealistic
canuck_in_wa@reddit
The second-system effect is very real. I’ve lived through it a few times.
https://en.wikipedia.org/wiki/Second-system_effect
SimilarBeautiful2207@reddit
In my company we have a product, first we did a migration from asp.net webforms to mvc 4, then years later from mvc4 to react + .net core 8. The result was always better than before but with less features.
danknadoflex@reddit
Usually it’s worse than before
Alive-Primary9210@reddit
I was hired to rebuild a legacy system based on Oracle to a new fancy event driven microservice based system using MongoDB.
The original system was 200 lines of ugly undocumented PL/SQL without tests, the new system was 10.000 lines with excellent docs and great test coverage.
When I delivered the project, I discovered that the team that was going to maintain it only knew Oracle, and they highly prefered the old system.
Agent7619@reddit
I wouldn't be enthusiastic about a replacement system that is 500x larger either.
Nofanta@reddit
Almost all of them. The positives hardly ever are worth the effort.
spacemoses@reddit
Why yes I have, thank you
shiversaint@reddit
.NET to node is just madness in almost all cases…wtf was he thinking?! I like node but man alive what an odd choice!
TopSwagCode@reddit
Once moving from dotnet to golang. Mainly because only go developer we had was tech lead and the others wrote c# like golang.
tmetler@reddit
If he has a huge Microsoft bias does that mean you guys didn't use typescript?
iMac_Hunt@reddit (OP)
Great question, luckily he was pro typescript. There was a general trend of him just not liking Microsoft products though
pl487@reddit
The quality of the resulting code is only part of the equation. It also affects the quality of people you can hire. Like it or not, many talented developers see .NET and click next, because they don't want to tie their careers to Microsoft.
I know, I know, it's not really like that any more, it's as open source as anything else now. But it doesn't change the perception.
rishiarora@reddit
Very common.
ForeverYonge@reddit
C# is a very decent and well supported language and ecosystem. I would be very concerned for any CTO that wants to migrate from it without exceptionally good reasons.
MonochromeDinosaur@reddit
Wtf, he made you change to a framework that emulates .NET (badly) and now you’re dealing with the consequences.
Sounds about right bad CTOs suck ass.
SolFlorus@reddit
Almost every single one has been a failure. My company has the attention span of a golden retriever. They say that they need to do the huge refactor, a month later something urgent pops up and we need to tackle it immediately, then after that is done we go back to the refactor again before the cycle repeats itself. Eventually they ask they the refactor is taking a year, then defund the project.
A half-migrated service is 10x worse than the orginal POS service. This is 100% a company culture problem, but it has happened to me 3 times so far at this company across a 7 year stint.
windfallthrowaway90@reddit
Tale as old as time.
AppointmentDry9660@reddit
🎶 🎶 ~~Beauty and the beast~~ 🎶 🎶
clamjabber@reddit
That's the usual
KronktheKronk@reddit
100% of the times
who_am_i_to_say_so@reddit
I cannot say it’s worse but the move still isn’t complete after two years and $2 million spent on moving it.
nighhawkrr@reddit
I’ve done many rewrites, but I also specialize in building new software from scratch. You really need startup experience to succeed at it.
toasterding@reddit
I've done huge refactors and ended up with something better than before but that's usually after doing a huge refactor and ending up with something worse first. "Second refactor is the charm".
choochoopain@reddit
Yes. Currently in the middle of one 🤣 Our .NET application was out of date (v5) and I upgraded it to v9. I asked the previous team leads (why aren't) on this team anymore why they decided not to upgrade, and the answer I got was "it was too hard". So, I'm the one that was caught holding the bag for this.
teratron27@reddit
VP of Eng decided that everything now needed to be event-sourced regardless of the usage and kicked off a project to move our core data models. 2 years later and we were constantly having to work around a half baked custom ES package and data inconsistencies and slow queries
Unfair-Sleep-3022@reddit
Luckily never.. but I've also been very measured about doing big refactors
SolarNachoes@reddit
What were the reasons given for switching?
vuongagiflow@reddit
Some migrations are unavoidable; doesn’t matter how painful it us the business has to go through or close down. Some of them are preference and knowledge loss; kind of idk. And worse thing is because of hype.
alien3d@reddit
you give me heart attack. But still heart attack