TLDR: it doesn't make (or save) money for companies in the short-term.
Not only this, but also 'agile'.
There‘s also the aspect of dark patterns that make up a huge bulk of Enshittification. They‘re making their software worse and let you jump through hoops simply to get you to spend more time and money on it. A lot of those hoops very much feel and probably sometimes are just bugs or inefficiencies.
This is something I really love about my job. It's a small company, and we don't have any of these kinds of process overheads.
It's accepted that people fuck up (and in most cases that're relevant to me, I'm the people in question) but if I can reproduce the problem, I can often get the fix in the users' hands the next day. Generally the positive effects of a quick turnaround and feeling like they matter outweigh the negatives of the problem being there in the first place.
Not to say I don't have stuff in the "tech debt" bucket, but having the autonomy to just fix the low-hanging fruit makes for a satisfying work environment.
Works for a small company. If everyone in a large company is allowed the same leeway nothing could ever ship - while no one person (except a few incompetent that get fired eventually) makes too many mistakes, the combination of all of them mean the system is always horribly broken.
Of course 50% of my job is just getting simple changes though which is annoying - but more than once that process has meant I didn't break everything.
Works for a small company. If everyone in a large company is allowed the same leeway nothing could ever ship
Oh for sure. I've been lucky enough that I've only ever worked for places with at most a few hundred employees, so my experiences of larger companies have been at best second-hand — but it was enough to know that I'd never want to work somewhere like that.
I've worked for both over the years. Small companies have their own downsides. There is no clear winner. People complain all the time, so if you have never worked at a large company you have no clue what it is really like. Sure there are things not to like, but there are also things to like.
Every company I worked for is like this. I sneak small improvements into daily work. If I call an old function, I'll often fix it while I'm there. Don't raise tickets. Don't ask. Just fix it.
I also have a shelf of a hundred fixes that I never merged. I've done the work, but the real hurdle is PR and and testing. It takes days of effort to push code that took an hour to write.
Exactly! I have the same, and sometimes I'll sneak in some fixes I have pending when I get the time to properly test it (usually in a boring meeting).
I’ve had whole projects falter because they wouldn’t get tested and a year later it was too much effort to reintegrate into the system which had moved on significantly…
At a previous company, I got in trouble for fixing a bug because the company made a significant portion of their revenue from paid customer support fixing data related to the bug.
Wow... that sounds like a whistleblower type situation. Unfortunately, whistleblowing doesn't pay the bills...
Not every whistleblower reveals their identity, just needs some proof and a good journalist.
Unless you have what it takes to be a celebrity
It’s a big company problem. Here’s why even obvious bugs like this one slip through the cracks:
The Tyranny of “Requirements”
In large organizations, everything revolves around the roadmap. If a bug fix isn’t tied to a specific requirement or feature, it gets labeled as “tech debt” and shoved to the bottom of the backlog. And let’s be honest: “tech debt” is corporate-speak for “we’ll deal with this never.”
The Rotating Door of Ownership
Over eight years, developers and product managers come and go. The person who originally filed the ticket? Long gone. The person who understood the issue? Moved on to another project. Institutional memory fades, and the ticket becomes a relic of the past. Even if the problem is still very much alive.
The Myth of “Quick Fixes”
A 13-line patch might seem trivial, but in a legacy codebase, even small changes can have unintended consequences. Without proper tests or documentation, developers are often hesitant to touch old code. The risk of breaking something far outweighs the reward of fixing a non-critical bug.
The Invisible ROI
Let’s be real: improving load times doesn’t directly impact the bottom line. Selling Shark Cards (GTA’s virtual currency) does. Companies optimize for metrics that show up on quarterly earnings calls, not for goodwill or user experience, until it’s too late.
I recently read that's one of the reasons Windows is so messy and bloated, time goes by and so do devs and managers, so it gets increasingly difficult to know what does what, and why.
That's true of any large old piece of software, I sometimes read my own code written a few months ago that I've forgotten and need to spend time to understand what it's doing, imagine reading someone elses code written years ago. Companies don't incentive good documentation or comments, and rarely have I seen proper coding standards enforced, so you end up with a lot of spaghetti code, with 600 line methods that do too many things and there may or may not be proper unit testing that covers this code thoroughly
And that's the same reason Linux and open source doesn't, because when developers are empowered to do things that impact them, shit happens
As a lead, I've recently started finding time to make progress on a lot of this, because a lot of the stuff I've seen over the years has just never been prioritized. Over the last few weeks I have:
You can do this as well. The problem is that I don't get any recognition for it, so this is completely driven by me making time for it and slipping it in w/ other changes. I document the more important ones, but I'm taking a risk w/ these fixes since any bugs I create in the process will not look good.
Whenever someone else on the team does something like this and is keeping up w/ their work, I try to lavish praise on them in the hopes that maybe they'll do it again.
Whenever the topic comes up with leadership, I try to explain it in financial terms.
Tech debt is just like financial debt. There are times when its appropriate and necessary to take on some debt. But debt accumulates interest charges. If we just keep building up more debt without ever paying it down, it'll eventually bankrupt the company.
The engineering team doesn't always know when the finance team is accumulating debt or paying it back, but we trust that they are doing so appropriately.
You don't always know when the engineering team is accumulating or paying off debt, but you need to trust that when we say we need time to to pay down tech debt, we're serious. We'll all be out of a job if we don't.
They don't usually like to hear it, but when put in those terms, they don't have an argument against it. I'm sure if we could provide a statement showing we had $478,562.78 in tech debt at 4.75%, they'd be more understanding about paying it down.
Fortunately, my boss is sympathetic, but unfortunately, our stakeholders aren't. We are given time for tech debt (10-20%), but that hasn't been achievable recently due to a huge focus on delivery. We just reorged, and we're trying to get a bunch of people new to our business unit on-boarded w/ our product, and they have a variety of requirements that we need to meet for that to happen. Things should settle down in a few months, but in the meantime, I try to fix some low-hanging fruit that directly improves morale for the team.
My org is better than most, I think, but it's still an issue here. It's absolutely crazy the difference between prioritized and unprioritized tech debt. For example, our architect wants a thing, so it gets done same day. Our dev team wants a thing, and it takes months, if not years. It's getting better, but like anything, it's two steps forward (finally got to trunk-based dev) and one step back (other teams whining about changes).
I think everywhere I've worked has said "we have 20% time for tech debt" but has never actually done that. It's always "we need to ship this by end of week" and "the CEO wants us to add the thing we said we'd cut so we could make the deadline".
So far, we've only had one or two deadlines come from outside the dev team, and up until this year, we got close to that 20%. So hopefully it's a temporary change due to our new CEO trying to catch up to our competitors in a few areas.
improving load times doesn’t directly impact the bottom line
Depends. In an online store earning $50,000 a day, a one-second delay adds up to more than $1 million in lost sales each year.
https://www.bigcommerce.com/glossary/page-load/
I never got into GTA Online because I couldn’t stand the long load times. So they probably lost a shit ton of potential customers.
If I got a dollar for every bug I've submitted that's in the backlog I'd almost be paid as much as the CEO
I too have been in the inside and I was one of those types who fought to do the right thing. The reason was much more simple to understand than this article…companies are run by sociopaths, psychopaths, Narcissists and doing the right thing is not their motivation. That said, while it might be easy to point the finger at them, they only get their power as soon as many kiss their ass and accept the wrong. You know…sort of like what is happening in the USA and most other country’s. We have a massive problem and we are not even really talking about it. Instead some want to blame capitalism and while sure it is part of the problem, you better believe and centralized human group has and will suffer from the same issues to varying degrees.
I dunno about the power part. They control the money. And they work with thier counterparts at other companies to make sure they continue to control the money. I too spoke out about doing the right thing to the PMs. My boss told me to knock it off because the leadership controls my pay, and they listen to the PM.
How come a small company has more leeway to afford such things like fixing old bugs, than a big one with more money?
No, don't answer. I know already, that small to medium companies are the better work place.
For the same reason a dolphin moves quicker than a blue whale: the company and software size matters, so decisions can go quicker thru the command chain and the code can be easier to manage.
Maybe large companies shouldn't create whale software then.
I always tell perspective employers that I don't want to be management. I care too much for the user. And I tell current employers that they don't want me in charge of priorities, because I prioritize tech debt.
I'm a manager. I prioritize tech debt by lying to my stakeholders. The only downside is they don't appreciate the cause of our stability. But it's the right decision for the company.
This is a most excellent place for technology news and articles.
