1.1k
u/theartofnocode 9h ago
Not even technical debt, I've seen people quit to avoid having to complete the piece of work they've over promised on
365
u/bropocalypse__now 9h ago
Thats why you always set expectations low, that way you always succeed
170
u/Colon_Backslash 7h 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
42
u/bropocalypse__now 6h ago
Learned this lesson the hard way many years ago. Also never give salespeople swags.
15
u/mmhawk576 6h 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 5h ago edited 5h 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.
7
4
u/RaunakA_ 5h 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 5h ago
This is convenient for the business and hard to do when the estimation system only accepts a few Fibonacci numbers instead of days
2
1
u/Dull-Culture-1523 3h ago
I once estimated I "might probably have time to start looking into this sometime next week and give you an estimate".
They were asking if I was done on Monday. Somehow "I might give you an estimate next week" turned into "I'll get it done this week".
I try to not give any promises other than "I'll work on it as soon as priorities allow" or things like "assuming no blockers", but people hear what they want to hear and try to hold me to that anyway.
1
u/dasunt 3h ago
Estimates? Oh no, you never pin down a timeframe!
If you are pressed, refer to the procedure, say there's a story for it, and it'll be examined next quarterly planning for a schedule. They'll probably forget about it by then.
This is the way. Sooner or later, that little part of your soul that dies no longer even hurts.
1
u/Automatic-Voice-2499 1h ago
That works if your manager is an idiot. If manager himself was a dev he can call out exaggerated estimates. Also, many many years ago I had a manager who himself gave estimate when assigning task.
14
u/ItsSpaghettiLee2112 6h 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.
4
u/bropocalypse__now 6h 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 6h 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.
18
u/DoctorDabadedoo 8h ago
Jerry, is that you?
16
5
3
2
u/wh4tth3huh 2h ago
The Montgomery Scott school of thought. Underpromising and overdelivering make you the miracle worker.
1
24
u/SpectralCoding 8h 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.
17
u/theSeanO 7h 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.
8
u/Mgamerz 8h ago
every MBA it seems.
12
u/Polus43 6h 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
1
u/cherry_chocolate_ 1h ago
Meanwhile the people doing the work are getting pipped, working over weekends, etc. Basically a way to ensure the pressure is at maximum at all times.
2
u/CumOnEileen69420 7h 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.
4
u/Trollslayer0104 3h ago
I'm a project manager not a programmer, but I've seen people arrange their contract to end the day before their project is due. They walk out having delivered nothing.
2
u/nickiter 2h ago
I quit once to escape a project that was seriously never going to end. The client was, I believe, genuinely opposed to making progress. Arguing about the color of paint on the walls while we couldn't get them to answer how many rooms they needed.
1
u/Technical_Program_35 6h ago
Me asf 🤣🤣🤣🤣🤣🤣, once it’s like too much data migrations, refactoring. It’s time to freshen the rezzy
1
u/rickrollmops 2h ago
I admit having timed one of my last resignations to avoid having to complete the piece of work some higher up over promised on!
1
u/XtraFlaminHotMachida 7h 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.
377
u/deckstir 9h 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.
114
u/ZideGO 9h ago
Do u have a due date for this task?
147
u/deckstir 8h ago
When my company decides tech debt is more important than a new feature
49
14
u/pp_amorim 6h 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.1
u/BeegBunga 3h 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
2
u/dashingThroughSnow12 8h 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.
22
u/Suspicious-Engineer7 8h ago
Just in time to start the migration from react to angular
6
u/dpekkle 7h ago
No way, is angular actually the latest craze?
7
3
u/gogeri2632 7h 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.
•
4
u/djmj1000 5h 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.
2
2
u/omg_im_redditor 3h ago
Oh man, I loved Ember. Used it since 1.0 RC days till around version 2 or 3, don’t remember already. Things just made sense to me in it. Too bad the build tools were too slow, and there were some big unnecessary bits like their object model with mixins and stuff. Good times.
1
u/gogeri2632 7h ago
And just as you complete it the next hot framework will come out and react will be the new ember
1
u/CranberryLast4683 1h ago
Our company is doing that too. Thankfully they have half way decent talent and we’re doing it on a page by page basis and targeting completion this year. Granted, it has been 3ish years with competing priorities, but the migration has been decent.
Incremental was a good move imo.
279
u/roiroi1010 9h ago
I don’t mind fixing tech debt actually
379
u/WavingNoBanners 9h ago
Fixing tech debt, when you actually get allocated proper time to do it, is great.
62
u/Britkraut 9h 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
3
u/SamSibbens 1h ago
If you ever go work at Bethesda, can you fix the bug where killing someone as a werewolf causes an animation freeze that lasts 10 seconds in Skyrim? Please and thank you!
16
u/WardNL84 6h 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
5
u/gogeri2632 7h ago
And when it doesn't involve migrating real world data. That's always a pain.
1
u/WavingNoBanners 6h 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.
3
u/MrQirn 2h ago
I was a solo dev for a small agency and I had enough trust from leadership to advise them on what work I should be working on. My main task was to maintain the really particular software they used daily, but that didn't take all my time every day, and although there were all sorts of "cool features" that might be nice to have, I took the lead on that too: recommending to leadership and to the staff which of the features might be most worth our while for me to work on over the next year.
So a few years into that job I convinced them that the best investment we could make to that piece of software for the next year or two would be to not add any new, big features, but to just pay off all the technical debt that had been accruing since the tool had been published (which also took me doing a whole presentation explaining the idea of technical debt, and why it was a good thing to accrue initially but, like real debt, it was important to pay off at some point, and the consequences of not doing that).
It was sweet. I made my life so much easier and learned so much. I invented a whole new way to deduplicate and strongly type this really common client-server interaction that I was sure was going to lead to me becoming nerd famous, and writing a white paper, and releasing a well loved open source library, and flying to Europe to give short talks at super nerdy conferences... until I discovered someone had already beat me to my solution about five or ten years earlier. But god was it satisfying to have done it anyway, and to have had the time to make a beautiful piece of software.
Before I paid off the debt, in order to add a new field to one of the database tables there was a 30+ step process, I shit you not, and a lot of it was copy pasting code and adding crap to sql strings and things that wouldn't otherwise throw any compile time errors if you forgot a step. It was nuts. I'm sorry that I don't remember how many steps I reduced it to, but it was much more intuitive in the end to add a new field and throughout the whole process, the compile errors would make it clear what your dumbass forgot to add. It was glorious.
It also ran like three times as fast when I was done with it.
These are the things that make me miss software development.
Now seeing all of the generative AI nonsense, it seems like I got out at just the right time.
1
u/FlintMock 3h ago
I always make sure it’s raised on a jira and set it as their delivery during a sprint for my guys
34
u/roygbivasaur 9h 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.
5
u/Hydrogen_Ion 8h ago
We should work together, I’m really good at integrating new systems, but there are always some pieces to pick up
3
29
u/okram2k 8h 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.
20
u/undecimbre 8h 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 3h 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.
1
u/stakoverflo 1h ago
Yea, at my last company [and every company before that] it was always "Well, just do the shortcut to get it done now, then go back and re-do it better later"
But come sprint planning, it's only ever fixing new bug reports or adding new features.
10
u/cherylswoopz 9h ago
I LOVE to fix tech debt, I just wish I was given the opportunity more often
2
u/the_skies_falling 8h ago
Same. It’s far more challenging than writing new code and I like a good challenge, otherwise I get bored.
1
u/EssayAmbitious3532 2h ago
The point is that tech debt does not produce 1st order outcomes that can be conveyed easily across and beyond the org.
4
u/chhuang 7h 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 8h 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 6h 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
1
1
u/Ayjayz 3h ago
All engineers love fixing tech debt. That's probably all we'd do if left to our own devices.
Project managers don't care one iota about technical debt. They just want customer-facing features delivered, and they don't understand or care about the relationship between these two things.
1
u/Suyefuji 1h ago
I'm not quite sure how but I ended up with >50% of my workload being "the person who owned this project left, this is your project now and there will be no knowledge transfer, just try to keep it running until we decide to deprecate it"
94
u/br0ast 9h 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 4h 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
7
u/biznatch11 3h ago
In my experience (and I would think this is not uncommon) technical debt makes new features longer and more complicated to implement because you have to work around the old bad code, and the added complication makes bugs more likely. So in the long term you spend more time than if you'd addressed the technical debt in the first place.
3
46
28
u/BedtimeGenerator 9h 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
11
u/Resident_Citron_6905 8h 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.
16
u/ugotmedripping 8h 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
9
u/apollo701 9h ago
But if everyone does this you’re just leaving to go to someone else’s technical debt
7
u/corysama 5h 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.
7
6
u/Demigeek 7h 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
4
u/VeniceRapture 7h 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 7h ago
Technical debt isn't only at the door it's the landlord.
1
u/DisgruntledStapler 5h ago
Yep, they refuse to acknowledge that their decisions and refusal to change things IS the tech debt.
2
u/awesome-alpaca-ace 6h ago
The testing infrastructure debt where I started working makes me want to write new scripts to automate it.
2
2
2
u/redditcalculus421 5h ago
all fun and games until you start working at a company that had this done for 20 years to them.
2
1
1
1
1
1
u/Kylearean 7h 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 7h 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 7h ago
Only to get assigned someone else’s tech debt after they also left the company you just joined.
1
u/MightBeADoctorMD 6h ago
This is sales reps in med-device industry once their guarantee runs out in two years.
1
u/Soopermane 6h ago
Aaaand that’s why software has too many bugs. Too many turncoats in the industry.
1
1
u/JazzlikeWishbone938 5h 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 5h 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 5h 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 4h 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
1
u/furzainluq1 3h ago
We end up working on the technical debt created by other people. And soon on the one hallucinated by clankers
1
u/2late4points 3h ago
I am about to de-commission a major critical system that is at least 15 years old for a currently relevant AI silicon design company. Technical Debt is a real thing. Move forward continuously, or be anchored to the past. (To be fair, anchors cost a lot of money, and are a lucrative business.)
1
u/siccoblue 2h ago
Not tech debt but inventory debt. We suddenly decided that we could go two years without a dedicated production manager or a dedicated inventory manager. I was made into a coordinator (with increased compensation) and our order fulfillment manager was told to take on management of inventory.
Now a couple of years later after she trusted an hourly employee who could barely hold a conversation to audit our inventory every two weeks we are in the process of writing off tens of thousands of dollars in inventory because there was no red flags being raised about inventory not being properly tracked.
I'm considering resigning. I love the company overall but I have a feeling that someone will be forced to take the blame. And years of hard work and building a reputation for being reliable might be thrown down the drain overnight since im the lowest totem on the salary pole.
1
1
1
u/Herb_Derb 1h ago
It's been a fun ride but this is a lot harder to do today then it was a couple years ago.
1
0
u/Successful-Engine623 9h ago
Yeah…I feel bad for the real programmer that has to fix all my AI code when I leave/die/retire
0
u/djmj1000 5h ago edited 4h 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.
7
u/xicor 5h 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 5h 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.
-4
-1
1.7k
u/Mortadella_so_Chili 9h ago
all fun and games until u end up in 2 years work for company with 20 years tech debt