by foxfired on 4/7/25, 8:03 PM with 120 comments
by cletus on 4/8/25, 5:42 AM
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.
by vanschelven on 4/8/25, 6:50 AM
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.
by star-glider on 4/8/25, 7:50 PM
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.
by _rm on 4/8/25, 11:21 AM
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".
by esafak on 4/8/25, 3:56 AM
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.
by charlie0 on 4/8/25, 3:45 AM
by SilasX on 4/8/25, 5:16 AM
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.
by robin_reala on 4/8/25, 6:34 AM
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.
by 7bit on 4/8/25, 6:52 AM
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.
by cainxinth on 4/8/25, 12:21 PM
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.
by bruce511 on 4/8/25, 4:26 AM
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.
by anonymousiam on 4/8/25, 4:37 AM
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.
by vjk800 on 4/8/25, 5:47 PM
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.
by nitwit005 on 4/9/25, 6:26 PM
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.
by jiggawatts on 4/8/25, 9:53 PM
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.
by p0w3n3d on 4/8/25, 6:43 AM
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.
by mvdtnz on 4/8/25, 8:57 PM
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.
by rmetzler on 4/8/25, 4:59 AM
by nickm12 on 4/10/25, 5:35 AM
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.
by darthrupert on 4/8/25, 8:23 AM
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.
by m463 on 4/8/25, 6:21 AM
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.
by Nezghul on 4/8/25, 9:13 AM
by thayne on 4/8/25, 4:39 AM
by mobilio on 4/8/25, 7:24 AM
by isaacremuant on 4/8/25, 3:52 PM
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".
by hulitu on 4/9/25, 9:12 PM
" 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
by dogtierstatus on 4/9/25, 3:16 AM
by charchica on 4/8/25, 11:48 PM
by josevalerio on 4/9/25, 9:06 PM
Many are saying this...
by xtiansimon on 4/8/25, 12:20 PM
by zoobab on 4/8/25, 8:01 AM
by BrenBarn on 4/8/25, 8:46 AM
by casey2 on 4/8/25, 6:01 AM
Also this article reads like AI slop particularly the "Why Good Bugs Go Unfixed" section.
by revskill on 4/8/25, 5:50 AM
by Galatians4_16 on 4/8/25, 3:32 AM
by sshine on 4/8/25, 7:44 PM
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.