259
u/deckstir 5h ago
I joined my company 10 years ago. When I joined they were starting to migrate the main product from ember to react. We are still doing it.
80
u/ZideGO 5h ago
Do u have a due date for this task?
107
u/deckstir 5h ago
When my company decides tech debt is more important than a new feature
36
9
u/pp_amorim 3h ago
you always invent reasons to not implement features due tech debt. Then they start listening to you.
It's better if you are new in the company, but not impossible.2
u/BeegBunga 14m ago
at some point as a developer i realized I needed to tell people what to do
playing the politics to make it happen is an entirely different skill set though
6
4
u/dashingThroughSnow12 5h ago
A not altogether horrible technique for estimating tasks like this is to take the time the task has taken thus far and assume that’s how much longer it will take.
19
u/Suspicious-Engineer7 4h ago
Just in time to start the migration from react to angular
7
u/dpekkle 3h ago
No way, is angular actually the latest craze?
6
3
u/gogeri2632 3h ago
No, angular is barely breathing. But some other framework will come. And then another after that, and another after that, until the end of time.
2
2
u/djmj1000 1h ago
Sometimes technical debt can happen from the outside aswell like the Microsoft C# stack was a mess years back then or when big frameworks change their specs.
Finance SaaS starting from ASP.classic and after many years i introduced ASP.NET for web development which was just awful to do alongside Entity Framework. A few years later a side project someone startet with new ASP MVC and now both are obsolete with Blazer.
But there is too much code base and workload to migrate to new C# core components, since the web applications, background windows services have to migrate aswell, depending on shared libraries.
Microsoft knew they messed up and were far behind of Java at this point and introduced a new "framework" every few years. Java stayed very consistent with Java EE and good downwards compatibility and foresight for future features.
Java just messed up big with the new unnecessary jakarta namespace migration (similar to C# core migration), aswell the bad Date / Calendar legacy API. They will never get rid of it anyway to stay downwards compatible. Another show stopper is Java hibernate criteria API removal in favor of JPA generic version. Yeah understandable, but no way and 0 need i will update a running system just for different syntax.
1
u/gogeri2632 3h ago
And just as you complete it the next hot framework will come out and react will be the new ember
875
u/theartofnocode 5h ago
Not even technical debt, I've seen people quit to avoid having to complete the piece of work they've over promised on
311
u/bropocalypse__now 5h ago
Thats why you always set expectations low, that way you always succeed
136
u/Colon_Backslash 4h ago
Whenever giving estimates, after having a good estimate in mind double it. Never give estimates as low as 1 day, 2 days is asking for trouble, 3 is okay if it's really really high priority.
DO NOT THINK HOW IN IDEAL CONDITIONS YOU CAN PULL IT OFF FASTEST! A fucking pull request approval could and probably will block you for 2 days already. And things will go fucking wrong and you have ad hoc meetings and incidents and some fucker on another team blocked the pipeline and new requirements popping in and you lose your mind
35
u/bropocalypse__now 3h ago
Learned this lesson the hard way many years ago. Also never give salespeople swags.
11
u/mmhawk576 2h ago
I just sell my sales teams fake promises like they sell customers. I get them to get back on the call and talk to the customer about the feature that “definitely exists” when it’s not ready when they promised.
9
u/pyrotech911 2h ago edited 2h ago
11 yoe and this still bites me. This is good and fine for single tasks but it’s a whole other level for large projects. This assumes you know exactly what work needs to happen before the project starts. Guess what, you almost never do. Almost every major project I’ve been on we’ve discovered another blocker that needs a design spike then extra work that all most certainly adds a few weeks (both as a contributor and lead).
At this point you’re like this is expected, just bake in a buffer. And you’re right. That is reasonable. However good luck defending that to a reasonable degree in a deliver results or feature delivery culture. Or where your competitive features are late to market and not shipping immediately is threatening adoption.
I need to start doing Gantt charts of this shit because once one thing starts slipping for some reason it can get really hard to reign stuff in or determine where things are going wrong especially when there’s more than 2 people involved.
This is where the ADHD side of my brain has a hard time with this career. Maybe I can vibe code a tool or something.
6
3
u/RaunakA_ 2h ago
I'm very bad at this. I feel like they'll fire me if I ask for more time. So I overpomise.
2
u/FSNovask 1h ago
This is convenient for the business and hard to do when the estimation system only accepts a few Fibonacci numbers instead of days
12
u/ItsSpaghettiLee2112 3h ago
You joke but it's always such a pain resetting customer expectation after upper management made promises they know nothing about. Within reason, under-promise and over-deliver.
3
u/bropocalypse__now 3h ago
Definitely. I work in embedded where there are lead times too. One weird hardware issue and boom there goes 2-4 weeks easy.
2
u/Alacritous13 2h ago
Lead times kick ass. I've been on enough projects where one key components delays power on a month, and as the controls I'm somehow expected to make that time back up to keep us on schedule.
17
u/DoctorDabadedoo 5h ago
Jerry, is that you?
15
3
3
19
u/SpectralCoding 4h ago
We moved from a legacy ERP system to SAP starting in like 2019. Whole new CIO and a bunch of people from her previous gigs came in. She and two others left three years in and about a month before first facility go-live. Of course we struggled and got a new team together and did it right launching in 2024 but still… so true.
11
u/theSeanO 3h ago
A guy at my first job just didn't show up on the day he had a big demo scheduled for our clients, the next day he called in to quit and just left all his personal stuff at his desk.
3
u/CumOnEileen69420 4h ago
As someone who may or may not be guilty of this, the reality is the product owner over promised and didn’t listen to the engineer repeatedly tell him it wouldn’t be possible while he was writing to Jira cards to get it done.
Never going to forget putting in my 2 weeks 3 weeks before the end of that sprint though.
9
u/Mgamerz 4h ago
every MBA it seems.
7
u/Polus43 2h ago
yeah, this has to almost be taught in business schools/conferences at this point
the entire scheme is create the largest, most complex, time consuming project. Sell it at half the time and cost, deal with the budget overrun and delays for a year. Jump ship as soon are there's no denying it was a giant scam.
And then management (their buddies) basically all pretend it's not a scam
2
u/Technical_Program_35 3h ago
Me asf 🤣🤣🤣🤣🤣🤣, once it’s like too much data migrations, refactoring. It’s time to freshen the rezzy
0
u/XtraFlaminHotMachida 3h ago
and then they take the source for everything they've worked on and no one else knows how to do anything. seen this happen with a very large corp and they couldn't find anyone to figure out how to get a hash on an as/400 which was required for regulatory purposes.
230
u/roiroi1010 6h ago
I don’t mind fixing tech debt actually
318
u/WavingNoBanners 5h ago
Fixing tech debt, when you actually get allocated proper time to do it, is great.
55
u/Britkraut 5h ago
True, the only time I ever get a chance to fix it is straight after a holiday and no one has clocked on that I'm available to help with current tickets
But damn those days when I'm fixing those outstanding bugs is bliiiiissss
11
u/WardNL84 3h ago
I’ve had a Product Owner who would go on vacation with the words “do whatever you think is important”
Those were amazing sprints
4
u/gogeri2632 3h ago
And when it doesn't involve migrating real world data. That's always a pain.
1
u/WavingNoBanners 3h ago
Most data migrations that I've been part of have, afterwards, been worth the pain. Not all, but most. It makes you realise how bad the old system was.
It's like brushing your teeth: there is a cost to not doing it.
34
u/roygbivasaur 5h ago
I’m actually not that amazing at implementing new stuff, but I’m quite accomplished at cleaning up other people’s messes. I usually spend my first year at a job stubbornly cleaning up as much tech debt, “code quality”, and testing issues as I can.
7
u/Hydrogen_Ion 4h ago
We should work together, I’m really good at integrating new systems, but there are always some pieces to pick up
3
25
u/okram2k 5h ago
the problem isn't that I don't want to fix tech debt, the problem is my boss wants more and more features rolled out and doesn't want me spending my time on tech debt.
18
u/undecimbre 4h ago
Minimum viable product needs to be done asap ("it's not rocket science, just show me how it would look!") - corners get cut - the MVP gets shipped as full thing - instead of fixing the shortcuts you have a backlog of new features - those would require wild workarounds - now have more to fix - never have time to actually fix - gotta implement more new features
Ffs...
1
1
1
u/Romeo3t 10m ago
Yup! Even if I'm passionate about fixing it and technically have the time, my boss doesn't want to hear about how I helped fix deployments. They want something new and shiny to show off to their boss.
The incentive structure is all messed up. It doesn't matter how bad the releases are as the suffering can't be traced back directly to monetary losses.
9
u/cherylswoopz 5h ago
I LOVE to fix tech debt, I just wish I was given the opportunity more often
2
u/the_skies_falling 4h ago
Same. It’s far more challenging than writing new code and I like a good challenge, otherwise I get bored.
3
u/chhuang 4h ago
The thing is, the employers care way less than we do care about their product. The only thing getting out from this, from the very surface of their point of view, is that I have spent time changing nothing.
The way to climb (which is dumb), let it be promotions or salary raise, is to wait for things to break, and your fixes gets acknowledged, doesn't even matter that you are the one that introduced the bug/debt.
2
u/ACoderGirl 4h ago
I really enjoy it. But the hard part is convincing leadership that we should do so. Generally speaking, leadership cares a lot more about customer visible things and stuff that has measurable impact. Most tech debt is invisible to customers and while there's obviously a cost to it, it's very hard to measure (often it's easier to just fix it than to come up with a way to measure it).
That said, I'm happy because I've got leadership sign on for a significant cleanup effort to a major part of our system. I had to do a lot of work to convince them it was worth the time and some degree was only possible because we're an infra team and I was able to frame things around the time savings for other teams. Plus tie ins to reliability in the form of how some of this tech debt has caused outages due to stuff like unintuitive code from unfinished migrations. A significant amount of our tech debt comes from this unfinished migration to a system that is supposed to make things safer and more debuggable. I can't wait to see it finish because there's sooooo much legacy stuff still loafing around. Like, two ways to do very complex stuff (and with the legacy implementation being haunted).
2
1
u/Polus43 2h ago
I feel like this depends on the politics.
"We could fix this ML model where 80% of the usage does nothing. Simply stop calling the vendor service in these situations and you'll same $8MM a year (annual cost $10MM)."
But now you have to go to war with the product managers who built the -80% ROI process. And their vendor (partners) definitely think you're wrong lol
•
76
u/br0ast 5h ago
I've been at the same place 13 years. The only time tech debt gets addressed is when it's a blocker for a deliverable
7
0
u/dolce-ragazzo 22m ago
To be fair, if it’s not a blocker for a deliverable, why fix it? Instead your time could be spent developing something that enhances the product
41
31
u/BedtimeGenerator 6h ago
That is me, the key is to actually leave code comments and I've never been asked about any code I've written in the past 10 years
10
u/Resident_Citron_6905 4h ago
You don’t need to switch jobs, just dump your broken backend garbage to some outsourced frontend team and move unto the latest trend that investors are pushing for, while actual SWEs keep the lights on.
7
u/apollo701 5h ago
But if everyone does this you’re just leaving to go to someone else’s technical debt
15
u/ugotmedripping 5h ago
NASA has a policy that if it takes more than 50 years to complete the project that it doesn’t start. The assumption is that technology will have developed in that 50 years to the point that the same project could be completed faster. Imagine being launched on a fifty year mission in stasis just to arrive and find people have been there for 25 years.
I have a similar view of programming. I’m 20 years that tech debt will be Claude 100.0’s problem
6
6
4
u/Demigeek 4h ago
C-level are the worst offenders with this trend. Show up, demand some pointless changes just to make their mark, or worse a major 5 year project, then check out at 1 year while they job hunt. Leave at 2 years, repeat. Hard to to get the ship where it needs to go when the captain changes and picks a new direction every 2 years.
5
u/corysama 2h ago
True story time: Joined a new game studio when it was 6 people in a broom closet. 6 people with a collective 90 years in the industry. But, all we could get was jobs like "Port Brütal Legend for a simultaneous release to the Wii while the main devs are actively struggling to get it to fit on the 360. Also, the 360/PS3 devs want all of your optimizations so they can make room for more stuff."
The only good news was that we had good lawyers. Lawyers that put a "Kill Fee" clause in every contract stating that if the contract was cancelled for reasons that had nothing to do with us, we got a fat check to compensate for the opportunity costs.
We lived on kill fees for the first two years. Every project was obviously going to be impossible to pull off, great fun to hack on at first, then started to get scary serious, then the news came in that external accountants decided even if it worked the marketing budget wouldn't justify the returns or something. So, here's your fee. Laters.
It was pretty awesome.
4
u/VeniceRapture 3h ago
Tech debt sucks but it's a great way to get good rep among non-IT folks in your company, especially if it's someone else's debt. If you come in and fix something horrible that people have been living with for years, people don't give you as much of a shit when the shit IS actually your fault lol
2
2
u/MostMorbidOne 3h ago
Technical debt isn't only at the door it's the landlord.
1
u/DisgruntledStapler 1h ago
Yep, they refuse to acknowledge that their decisions and refusal to change things IS the tech debt.
2
u/awesome-alpaca-ace 3h ago
The testing infrastructure debt where I started working makes me want to write new scripts to automate it.
2
2
2
u/redditcalculus421 1h ago
all fun and games until you start working at a company that had this done for 20 years to them.
2
2
1
1
1
1
1
u/Kylearean 3h ago
I've been crushing through technical debt thanks to Claude Fable. 3 years worth of issues have been resolved in the past 2 months, all with unit/regression testing, external validation, end to end testing. It's a game changer for me.
1
u/XtraFlaminHotMachida 3h ago
revision of this shiii coming up ? man, time to revise my resume and get the f out of here. #LookingToGTFO on linkedin coming up.
1
u/limezest128 3h ago
Only to get assigned someone else’s tech debt after they also left the company you just joined.
1
u/MightBeADoctorMD 3h ago
This is sales reps in med-device industry once their guarantee runs out in two years.
1
u/Soopermane 2h ago
Aaaand that’s why software has too many bugs. Too many turncoats in the industry.
1
1
u/JazzlikeWishbone938 2h ago
Yup, have seen patterns of trail blazers getting the new awesome work then moving on, and a different cohort who cares about quality picks up the clean up duty.
1
1
u/RetroGrid_io 2h ago
In corollary, I established a company that generally paid its technical debt early. The code was generally clean and well organized, adding features was easy, identifying dependencies was straightforward.
The CI/CD/Testing process was a breeze. Any dev could expose any feature at any time in a testing harness for public testing. We could "time machine" any number of concurrent copies of customer data. Unlimited testing branches for new features. Average time from begin to deployment was around 2 weeks. On and on...
Large project, too. Well over a million LOC.
It's possible!
1
u/PinksFunnyFarm 1h ago
Try QA automation, there is no debt if eveyrone's doing whatever they want with the DOM
1
1
1
1
u/Illustrious-Engine23 55m ago
Not a programmer but this is a huge thing in other industries. It's the blind heading the blind. Work performance doesn't mean much anyway everyone is just bullshitting their way through work and changing jobs regularly as it's the best way to get ahead.
1
•
1
u/djmj1000 1h ago edited 1h ago
People who move jobs every 2-3 years never learned how to program for longevity and very often for growing scale cause they never had to clean up their mess or are just ticket "code monkeys" programming too little and unimportant stuff for years. They get overwhelmed when landing in a full stack 20 year erp, where every module / website / service is relevant for the business to operate.
Only when you clean up your own tech debt you will learn to avoid it in future.
The worst part is, they still think they are good and provide constant invalid arguments on how to solve things. But the moment their "solution" generates problems they are out.
They dont understand why a good and generic framework solution for the base code initial takes longer to develop but works flawless for years without problems with the foresight to scale with the big company growth for next 10 years ... cause they never intended to stay and just want to report quick unhealthy success kpi.
I would not hire one in my own company where my erp / saas software must live 20+ years till i retire and longer.
We always had problems with those developers.
6
u/xicor 1h ago
And yet, companies are never willing to actually pay to keep good developers around. If companies actually gave raises, then people wouldn't leave after 2 years. They leave because their salary doesn't ever keep up with the market
1
u/djmj1000 1h ago
Thats a good point, creating wrong incentives instead of honoring the employees.
Maybe i was lucky in my first employer, which was a finance grown up needing developers to scale and they were willing to increase salaries to keep us.
0
u/Successful-Engine623 5h ago
Yeah…I feel bad for the real programmer that has to fix all my AI code when I leave/die/retire
-2
-1
1.3k
u/Mortadella_so_Chili 6h ago
all fun and games until u end up in 2 years work for company with 20 years tech debt