A lot of the time, a lack of bugfixes comes from the incentive structure management has created. Specifically, you rarely get rewarded for fixing things. You get rewarded for shipping new things. In effect, you're punished for fixing things because that's time you're not shipping new things.

Ownership is another one. For example, product teams who are responsible for shipping new things but support for existing things get increasingly pushed onto support teams. This is really a consequence of the same incentive structure.

This is partially why I don't think that all subscription software is bad. The Adobe end of the spectrum is bad. The Jetbrains end is good. There is value in creating good, reliable software. If your only source of revenue is new sales then bugs are even less of a priority until it's so bad it makes your software virtually unusuable. And usually it took a long while to get there with many ignored warnings.

Personally I've never found it a problem to just fix things that I see are broken, as a dev, without PM approval, even in very dysfunctional organizations. Sometimes it even goes noticed and people applaud you for it.

In other words: though I acknowledge that the phenomenon described in the article is real, I sometimes feel it's just because developers accept a reality that doesn't need to be accepted.

This isn't effective at a large org, but if you're running a small company/startup, just have an engineer "help out" with support every so often. We'd ask devs to run the support desk when the person was on vacation and also had a general rotation through.

It's good for building customer empathy but also for helping the people who build the product understand how it's used. The intuition you build up from those experiences is very powerful.

Also, about two hours into handling support tickets for the same issue, 99% of devs will just fix the problem. So you create a very elegant incentive structure for bugfixing that circumvents a lot of the traditional structural issues.

Of course you can't do this in a big company, which is one of the structural disadvantages that come with size.

The solution to this is just build competitors and prey on their market.

It's basically impossible for companies to get managers who can perform at the level required to not end up becoming a blunt instrument "more features now" shitshow.

Just find companies that have reached this stagnant state with deep backlogs, subscribe to their product and study it, rebuild it from scratch the right way, and stick ads on that company name as keyword.

Then when you eventually start strangling them and the MBA simpletons at the top knee jerk with cuts, poach their best staff they didn't cut, and ask them "of those they cut, who would you have kept", and reach out to them.

Basically the only way this situation gets "fixed".

It depends. Some other reasons:

1. It's an enterprise product and the economic buyer doesn't know or care about bugs as much as checklisted features.

2. The company is not connecting the impact of fixing bugs to their bottom line. Or they are and estimate the impact to be low.

3. The code base is due for a rewrite so it would be a waste.

4. It's a side bet not worth the extra resources.

This is exactly what happens when Product completely takes over the dev. team and they aren't given any control over their craft. Dev. team should always have x% amount devoted to things by devs for devs.

To repeat my litany of shirking:

1) We don't need software tests because we have a QA team.

2) We don't need a QA team because we can just watch for user bug reports.

3) We don't need to watch for user bug reports because anything that actually matters will show up in the usage or sales stats.

4) We don't need to watch the usage or sales stats because it's redundant with our general financial picture.

5) We don't need to watch our general financial picture because we already have a canary in the form of repo men hauling furniture out of the lobby.

Different companies have different standards for when they start noticing and caring about a bug.

I’ve personally always liked firebreak sprints. Every so often (3-4 times a year) in between other large pieces of work, take a week and give the developers free reign to individually fix the things they think are most important but never seem to get prioritised.

Yes, it talks to a disconnect between product and engineering, but working on that relationship at the same time doesn’t mean that both aren’t worth doing.

Discord has a bug where using the HOME-SHIFT key does move the cursor without selecting the text, when creating a new forum-type post through their desktop and web client. In addition, the HOME and END keys also jump to the start/end of the textbox, instead of the start/end of the line.

They closed the ticket and sent me to their feedback page, where I can request any new feature, where people can then vote. They concluded their rejection with the phrase "anything is possible" with the help of the community.

I created the same ticket 5 years ago, where it was treated exactly the same.

It is so frustrating as a user to have basic functionality broken and repeatedly running into this on a weekly basis, because habits... and then getting told that they don't care about the bug unless thousands of people discover your bug report in their feedback portal and up vote it--as if it were my job to do the prioritizing for them.

It's quite upsetting.

> The Rotating Door of Ownership

It’s this one. And it happens in every industry. Things fall through the cracks because no one wants to take responsibility for covering the cracks. And that’s because it’s generally a thankless job. The company Swiss Army knife / fixer / keeper of institutional knowledge is quietly holding things together while the upwardly mobile types ensure the spotlight stays on them.

Let's be clear here; Companies fix bugs. Lots and lots of bugs.

What this article refers to are "some bugs". And while corporate inertia can play a part, bugs get ignored for all kinds of reasons. It's very hard to be generalistic about this.

For example, some bugs aren't fixed because they are very hard to duplicate. When a bug only happens rarely it's hard to debug it, and harder to know that the fix is working.

Others are related to external environmental factors. Thing like AV behaving badly, or interacting with the machine in weird ways.

Sometimes the bug report is so vague, and lacking in detail, that frankly it's useless. I can't count the number of "what have I done wrong" questions which seem to think I'm psychic.

Some bugs are hard. Very hard. Folks have a crack at it, but after some time give up, and move onto other things. Often in these cases the "fix" can be worse than the bug, having various side effects and so on.

In some cases bugs are left in, because to fix them would be to break other things. For example bugs in say the C standard library, if fixed, might break programs that depend on, or work-around, that bug.

This is the tip of the iceberg, there are almost as many reasons as there are bugs outstanding.

And yes, there are very corporate reasons regarding resource allocation that prioritizes some bugs over others, or new features over bugs.

One item was missing from the list:

If you have some annoying bugs in your product, your customers will rush to purchase the next release, because they'll believe that the bugs will be fixed.

Microsoft has used this strategy with enormous success.

> 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 don't know... I quit playing GTA V once because of the horrendous load times. After I built a new computer, I finally finished the single player, even though the load times were still horrible. I also had a bug that randomly when I started the game, fps would be really slow and some of the textures didn't load.

The game was great, and maybe I would have gotten back to it to also play the multiplayer, but the fucking load times made starting up the game feel like a chore. I mostly play games when I have a little spare time in the middle of my work day, and I don't want to waste that spare time staring at loading screens or rebooting the game because of random bugs.

The GTA performance bug didn't get fixed because back when they were trying to make the game performant, there was no problem. They kept adding new stuff to the online part of the game, and the file being parsed grew to be ridiculously large. The person who fixed the bug mentioned "63k item entries": https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...

The economics of these games requires that you remove most of the development staff after launch. The games cost hundreds of millions to develop. Everyone went off to go work on GTA6 or some other title.

> Let’s be real: improving load times doesn’t directly impact the bottom line

Yes, it does!

I was agreeing with the article until this point, which is simply false.

When the GTA bug made headlines, several articles about it estimated that it cost about a billion dollars in lost revenue because players got fed up waiting and switched to a different game.

This, right here, is the real tragedy: Performance is a feature — but practically nobody recognises it as such.

Apple does.

Remind me, what are they worth again? How many trillion dollars?

Would they be worth that much if the iPhone just froze for seconds at a time, randomly, all the time? Or took ten seconds to unlock? Or any number of similar issues that aren’t “features” in the minds of incompetent management, but was a key requirement enforced by Steve Jobs?

No, they wouldn’t.

Yeah, I've been there and seen that. These prioritization things, these bug burrowing in Jira actions, etc.

However this is only showing that companies must start changing their priorities. For what I see on the market right now, the only currency for companies is money. I know this sounds stupid right? No, what I mean it used to be trust. The trust used to be the currency. I remember HP replacing my monitor to a new one only because I called them. There was no verification, the courier arrived WITH A NEW ITEM and took the old.

Now the trust is on the last page, if someone dares to say it's even there... Companies care about their investors, investors care about stock prices go up. There is no human satisfaction in this feedback loop. At least not the majority.

I used to work for a company called Xero that makes accounting software. We prided ourselves on making highly user-friendly "beautiful" accounting software. At the time we had a team (with the incredible name The Sniper Team) who were dedicated to hunting down and fixing small bugs, papercuts and UX issues. They had a tremendous positive effect on the codebase, the product and customer happiness.

I guess the concept wasn't paying off because the team was disbanded, as was the forum we used to communicate directly with our customers.

In my book this is an incompetent PM who doesn’t test anything by himself. If he would have to sit through the JSON parsing a few times every day it would have been fixed in a matter of days.

I don't see much mention in this discussion of how agile development impacts both the rate of bug creation and bug fixes. I only have my personal experience, but I suspect agile both encourages buggier software and longer-lived bugs than other methods.

The problem I see with it is the time-boxed sprints.Developers are rewarded for completing "stories" on time, not for the quality of that work. If a bug is found, they are rewarded for fixing it on time in another story (but only if it is high enough priority to warrant making it on the sprint board).

My experience is that getting it right the first time takes meaningfully longer than getting it nearly right, and agile rewards getting it nearly right. This is fine in the short term, but eventually the system grows a lot of subtle bugs, which add up to some big bugs that are expensive to fix. These take all the bug fixing time and the subtle bugs languish for attention.

As an architect, I fix bugs and do other kinds of maintenance. I don't ask for permission. It's a part of the job.

If you are in a team where the management doesn't allow you to fix bugs, it is your responsibility to lie to your management and fix them anyway.

Fearing a loss of employment is of course a valid reason to let a product rot, but that doesn't completely free you from this responsibility.

There's a heirarchy of bugs.

Is it a crash? higher probably it will get fixed.

Is there a workaround? that lowers the priority.

Performance problems like the GTA loading bug are hard to quantify.

Has a bug even been filed? Maybe not because over the internet it is slow, but on 10g developer network it never shows up.

And if it has been filed, who's to say it doesn't take that long to load. Expensive engineer could spin on that one with no resolution.

In my last company I had like 10 product managers above my head. Each one was managing a bunch of new features ordered by different clients. As a developer you could work with different product manager every day because every task was linked to specific product manager. Do you think any of them would care about such bug that do not block their precious feature for which they will get bonus if it's done in time? Of course not. And if you tried to speak with someone higher about that issue you would hit the wall of "And which client will pay for us fixing our own bugs?" As if better product would not have better marketing and bring more money in the future. Everything is always about money now. Monkey sees money - monkey has neuron activation.

It isn't just big companies. Bugs get buried at all stages of a companies growth, for similar reasons.

Here is GTA JSON bug: https://news.ycombinator.com/item?id=26296339

Having a product manager saying what "devs" should do is part of your problem.

Your tech leads should get to say what you work on a be very aligned with business needs but also understand where tradeoffs are worth it.

The article does make good points 1-4 which basically boils down to "there is an incentive gap and no one will want to sacrifice themselves to pick up this slack".

> Why Companies Don't Fix Bugs

" It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8? " jwz

I test enterprise software and I can tell you there are always a list of "known" bugs in the backlog that never gets fixed unless an existing customer asks for it. This is the case in every large org I've worked in.

Just do the thing! https://josevalerio.com/just-do-the-thing

Many are saying this...

This resonates with our team. I've seen the same issue show up now 3 separate times over the past several years, caught in this same cycle. For better or for worse. Likely for worse.

Huh. I work in finance related industry and was reading this for insight into the lack of forward movement in important software features—-opposite condition of the OP’s context of gaming.

Because laws are badly designed, there are no liabilities for buggy software products.

The short answer is (as it so often is) money.

Because they hired "web devs" when they wanted systems engineers.

Also this article reads like AI slop particularly the "Why Good Bugs Go Unfixed" section.

Deadlines cause bugs.

Talking about 343 industries? Edit: No, but yes.

In one job, I found three exploits. I did the analysis / writeup, and a pull request, and they collected dust for 4 months.

I don’t know why. Maybe it was political (acquisition and certification). Maybe they didn’t understand or recognise the statistics that I used. Maybe they didn’t think it was a problem, since they assumed that no incidents had happened.

My impression is that the buggier the code, the less they care about security if it hit them in the face.