Anyone else abhor months long tasks of "upgrading a stack"?
Posted by No-Garden-1106@reddit | ExperiencedDevs | View on Reddit | 47 comments
This is migrating from one "older" tech stack to another, my examples are mainly in the front-end but can also apply to back-end. I feel like they really don't add much value to my career as an engineer and I can't see it being a "that was time well spent". Of course companies have had to migrate from CoffeeScript to TypeScript, Angularjs to Angular, Vue 2 to Vue 3, etc., but I just find myself zoning out and trying to just do other tasks. I'd read a blog post from the framework authors on something about how it's "seamless" and you know there is going to be a weird gotcha (context: we've tried the Angularjs -> Angular for a big app and we eventually just rewrote.).
I am fine with migration tasks re: extracting out a monolith to a microservice or moving parts of the data from one DB to another or converting an FE project to use turborepo, and of course normal upgrades and migrations, it's just the software upgrade processes that I don't enjoy doing, and don't see being asked in a tech interview ever (or you can have an answer for it as a contributor who follows instructions, but not as a lead).
Anyone else feel the same way/have tips to appreciate it more? I know I need to eat my software vegetables, but I don't want to eat this one lol.
Sweet_Television2685@reddit
it is not just upgrading a stack, it is essentially a migration project
ktwrd@reddit
Where I work pretty much all of our apps are legacy and should've been replaced many years ago, but every attempt at replacing them has failed. Luckily we only have a few VB6 applications (which are too massive to migrate to any other language or platform anytime soon) and one terrible ASP WebForms application that takes >30min to compile for debugging...
Once of those VB6 applications has slowly been getting replaced since 2019 and it only has implemented a handful of the features in that application (and there are about \~100 features that are all required), and at my work there has been efforts for years to migrate old .NET Framework Web Applications to .NET Core, which all fail due to scope creep or they are too much effort.
GammaGargoyle@reddit
I find that if you keep your dependencies updated continuously, it’s not very hard at all.
touristtam@reddit
That's a big if, that. There is a whole population of devs that are following the mantra: "thy shall pin down the dependency version and never look at them again". And, yes, I know, that is a valid concern to not air on the bleeding edge for the sake of it.
latchkeylessons@reddit
I enjoy that work. You know it's necessary and valuable rather than some stupid thing executives push down that may or may not ever see the light of day in production. Upgrade paths usually also are good learning opportunities to figure out what breaks along the way. They can be good talking points on a resume also if it's phrased well particularly since at scale there can often be large cost savings associated with reducing complexity or performance benefits on more modern releases of XYZ framework(s), leaving alone security concerns and risk management reduction, etc.
MisterFatt@reddit
Months? lol, how about years? I’ve seen what happens when you just flat out ignore major upgrades. Better part of a decade spent upgrading from python 2.7 -> 3
Weasel_Town@reddit
I see your python 2.7 —> 3 and raise you Spring Boot 2 —> 3.
safetytrick@reddit
Spring boot 2-3 was easy, 1-2 was pretty painful though.
IvanKr@reddit
Been there done that. You have to go one minor version at the time and scour the Internet for cryptic errors until they are solved. Trick I learned along the way it that you can put a breakpoint inside dependency code.
new2bay@reddit
Bah. Just upgrading the ORM at one of my jobs would have been a years long project for an entire team.
No-Garden-1106@reddit (OP)
Yeah I was being polite on the timeframe lol. I mean, I am proud of many things of software and being a software engineer, doing other migrations to make the software better, but I do not want to spend a hundred, two hundred, whatever hours of my life doing JS/Python/Ruby/whichever upgrades, all of that shit. I just don't see the point of it and I would rather just get kicked in the nuts every day cause at least after it hurts, I don't have to think about it that much.
MisterFatt@reddit
Yeah it’s not fun. A silver lining is that it can be an opportunity to do refactors if you enjoy that. My team is very happy to hand off this type of work to our offshore teams
teerre@reddit
The only reason it took so long is because the python project maintaners refused to simply drop support for 2.7 earlier. If they had dropped supported when Python3 released, a bunch of people would complain, but in a couple months everything would've been fine. The actual, technical migration was really simple, the problem was mostly political
hibbelig@reddit
I don’t enjoy cleaning my wind shield, but I know that I can see better through a clean wind shield, it helps to avoid accidents.
I don’t enjoy these upgrades, but I know the new version gets security fixes, it helps to avoid security incidents.
No-Garden-1106@reddit (OP)
no, I get it but cleaning the windshield doesn't take months right? believe me, I love fixing stuff up in software but this specific task is just not a thing that I enjoy doing. If you don't mind me asking, what is the part of software engineering or development that you would rather not do?
hibbelig@reddit
I worked for an international company as one of the few developers in Europe. When I started I wrote software, but over time leadership told us to let folks from the subsidiary in India do the work. So my work morphed into whipping Indians. This aspect was horrible. I avoided it as much as possible, and in the end I left.
fixermark@reddit
Oh, sure. They shifted you from machine management to people management. Totally different area of expertise.
hibbelig@reddit
It’s not just that. I admit that people management is not my thing but I’m happy to mentor people and I’m also happy to do some coordinating work, as a senior developer should.
But here it was just about making the poor colleagues in India feel bad about their workload, to demand from them, to push them harder. They were so overworked that they would just do the task for the person who shouted loudest. I don’t want to get into a shouting match.
It was normal to have daily status calls to all about progress. Then people discovered the twice daily status calls in order to shout, if not louder, at least more often.
Very demoralizing. Very demoralizing.
80-90% of IT in the US was Indian and they knew how to work with the Indians in India. I’m a European and i don’t like to play this game.
I hope this clarifies the difference between your description as people management and the situation on the ground…
fixermark@reddit
Not only do I abhor it, I look at the big chunks of the world still running on COBOL and strongly suspect it's just a scam by big stack to gain reputation by having people on their stuff instead of the other guy's stuff.
There's a certain rat-race to stack architecture; I fear it's too easy to get sucked into being on the new-shiny at the cost of solving real problems for real users (none of whom's problems are "Ooh, I hope the company that manages getting me my paycheck on time is using the best stack!").
Adept_Carpet@reddit
It's funny that no one ever asks about that in interviews because a good answer to "how do you deal with stack version upgrades?" sits in a very happy middle ground between "failing the interview because I can't remember every named argument to this infrequently used function while standing at a whiteboard" and "someone who has never programmed before can bluff their way through it."
A good answer is really valuable, though I'm not sure I've ever heard one. Failing that you're probably better off if everyone on the team has the same bad answer. Some people deal with this by jumping right on every upgrade, others only upgrade when they need something or there is a critical security issue, and some will even backport critical security fixes to avoid upgrades even longer.
All those approaches can work, but not together.
Weasel_Town@reddit
I was the point person for an absolutely massive uplift. Company’s flagship product, some stuff was literally decades old, company suddenly cared when they pursued FedRamp certification. And I did a good job. Broke it down into manageable chunks, imposed enough testing that we had very few regressions, and we succeeded. So the best case scenario for doing this.
You know how much resume building I got out of that? Zero. At first, I was dumb enough to brag about it in job interviews. But it was treated like I was bragging about my good comments or something. No one thinks it’s difficult or valuable until they have to do it.
MisterFatt@reddit
I feel like you’ve gotta pick your spots for bragging about something like that. I could certainly see a situation where a company is looking specifically for that type of experience. If the team is working on launching an MVP and doing tons of greenfield development, some guy talking about stack upgrades would not be super compelling
Weasel_Town@reddit
For sure. Everyone wanted to talk about bringing new products to market exclusively, including companies who haven’t brought a new product to market in a decade. It’s like they think that’s the only hard part.
Ok-Kaleidoscope5627@reddit
That would be a question for a staff, or higher level engineers.
The coding challenges are what they are and anyone that thinks a single approach works across the board has probably only worked with one stack. Anyone that thinks interfaces and abstractions will magically solve the problem is just reciting answers they read rather than what they know from experience.
You can get into weirdly specific things involving moving from one version of a library to another specific version but that's so specific to that library that unless you're hiring them specifically for that migration, it's mostly irrelevant.
Which leaves discussion around policies and standards to be the real discussion to have and that's only relevant to the engineers who would be deciding those kinds of things. Hence staff+ engineers. As for their answer, I'd expect it to be focused on asking insightful questions about how development is currently done, and what sort of policies and standards would improve the process and their philosophy on what makes sense and why in that particular situation.
saposapot@reddit
Having experience in those kinds of migrations is a pretty great skill to have on your CV. It’s a business need that happens often, specially now that companies want to keep up with security vulnerabilities and software gets deprecated.
A lot of folks turn that into a consulting career because, again, it’s a very needed business opportunity.
Personally I don’t particularly hate as it’s usually accompanied by feature/design improvements so it’s usually like doing a new feature with just an old code point of reference.
On the backend it’s much more boring but on FE i don’t feel it
silenceredirectshere@reddit
I might be just weird, but this is my favorite type of task, not sure why. My teammates love me, lol.
opideron@reddit
In general, the best approaches I've experienced are mostly along the lines of "build a new facade" that interfaces with the old stack as is, and "recreate critical functionality in the new stack". "Upgrading" a stack typically doesn't work unless it can be done in a seamless way in a week or two.
Why? Because an "upgrade" typically implies all sorts of vague requirements that it should work like it did before. Whereas having explicit requirements for a function or an API means you can rewrite it in any language/framework and meet those requirements. Creating a new method requires only testing that method. Upgrading a stack requires testing "everything" because anything might break.
beaverusiv@reddit
I guess I'm in the minority then loving this type of work. I'm much more comfortable in a mature codebase cleaning up tech debt, upgrading packages watching the code look nicer and more readable as I blast through it
No-Garden-1106@reddit (OP)
I mean I do like fixing these kind of things. but again there has to be a limit right? let's just say you needed to upgrade vue 2 to vue 3 with like 200 components across 10 engineers. Is it still fun then?
beaverusiv@reddit
I am partway through upgrading an 800k LOC app with 300 components from React 15 to 18. I am 3 years in, along with other feature work. I love it
beaverusiv@reddit
Change component library from dead `react-toolbox` to Mui, convert to Typescript, remove Redux, convert all components to functional, upgrade to better code style... it's amazing the transformation and the improvement in testability.
EOengineer@reddit
My professional life the last 6-7 years has been heavily geared towards upgrading and modernizing Rails stacks. The last 2 years have been the most challenging tackling a massive monolith that started as a Rails 3 app, was Rails 5 when I got here, EOL Ruby versions, Carrierwave 1, a bunch of unmaintained custom gem forks. The works, as they call it.
I singularly own this process in an org that historically has very poor stewardship of their codebase’s health. I’m also working on that, having to manage up, etc.
There are good days. There are bad days. I’ve been giving more and more thought to going out on my own and offering what I do as a service.
Ignisami@reddit
Its better than the alternative, exemplified by the rick and morty meme.
"In and out, easy one month upgrade" progressive insight happens one year later "Maybe next year. Fuck Oracle." (Srsly tho, we were passed when we discovered Oracle weblogic 14.1.2 supports Jakarta 8, not 9)
Puggravy@reddit
I'll write tests all day before doing that but it's necessary. 🤷♂️
Impossible_Way7017@reddit
I won’t be volunteering for anything like that anymore after upgrading a mono repo to spring 3
cougaranddark@reddit
I haven't had to so something like this in a while, but if/when I do, I'd look forward to seeing how tools like Cursor could make it less painful.
UsualNoise9@reddit
I’m gonna get hate but have you considered getting AI help? Look into GitHub copilot agent. Vscode insiders has the button - not sure if it’s arrived at vscode stable
No-Garden-1106@reddit (OP)
AI makes things a bit better in this way. I'm not against AI to assist doing this. But again, a sprint has a certain amount of tasks per time frame. I want to do literally anything than this. This is like along the lines of fixing something for some dude using an iphone 5 with 320px breakpoint in 2025, that kind of a task. A "what even is the point of this" but extended across months. I can just move teams or hopefully move teams or work on something else and then just wait for the thing to get done. And then, "alright, thanks fam for the upgrade".
UsualNoise9@reddit
That's a more philosophical question. About 50% to 70% of projects I've worked on in my career were pointless. Of the remainder, half never saw the light of day. Ask yourself why you're with that employer: is it the paycheck? the people? if you value meaningful work more than anything else, maybe it's time to consider other jobs. Personally, I signed an offer literally 1 week ago to get out of a dead-end project onto something more exciting while taking a pay cut.
No-Garden-1106@reddit (OP)
That's awesome that you have that clarity! It's not a problem with the employer - it's just this specific type of task. For example, migrating to TurboRepo or migrating to Kafka. That could really well be something that doesn't work out or the company can scrap it, but at least the journey of figuring out how to get to that upgraded state, has some payoff of either learning a new technology, or a new paradigm, etc. A software upgrade is literally, just an upgrade most of the time.
UsualNoise9@reddit
I mean that's kind of exactly what I am saying: in any job there's going to be tasks that suck. Those are the times you remind yourself why you work at that job in the first place. Either the other stuff outweighs the suck or it doesn't. The suck won't go away - the only thing we can do is choose to deal with a different suck at a different job :)
IncandescentWallaby@reddit
This is exactly what I use AI for. You have tests to know the answer so you can check the work.
Just point at the code and say make it do the same thing but less bad.
horizon_games@reddit
Agreed it's really annoying, same with the constant churn of packages and version updates even within the same framework.
Migrating one framework to another 1:1 with the same screens and everything is hugely boring. No real way around it. Maybe try to see if parts of the app can also be improved alongside while you're doing the upgrade. Or use it as a learning experience if you're going from say React to Angular.
lessthanmore09@reddit
I didn’t realize till your post how backend-heavy my resume is. Sounds like you’ve done enough FE framework hopping to exert authority on the next one though, as a silver lining.
No-Garden-1106@reddit (OP)
Yeah, actually the same is for back-end too. I remember older engineers talking about the damn Rails 2 to 3 upgrade, which was so long ago. But again, right now it's already like Rails 8 or whatever, right? And then it's just like part of my life is just happy that I never did that.
If a task was to extract stuff from Rails monolith and make it scalable in another language, yes, this is hard nand needs planning, but at least I there is fulfillment there. I can be proud of that. But the upgrading is just, as long as it could fit in maybe like a week or a month with milestones, it's fine. More than that, with a PR/PR chains stuck in permanent limbo, please shoot me.
exploradorobservador@reddit
This is why I've sort of moved away from JS and front end for career, too much depends on dependencies with breaking changes because the library authors found the next best way to do things. React Router, React, etc.
zica-do-reddit@reddit
Yeah it's a drag. I guess it speaks something about software quality; platform/framework updates shouldn't be the pain that they are.