Why Companies Don't Fix Bugs
idiallo.com
idiallo.com
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.
Recent example the removal of the commit modal.
Nowadays they copy Vs code instead.
Don’t get me wrong, I love JetBrains products. However, there value has been almost exclusively in QoL for dev. AI is drastically cutting the need for that.
https://youtrack.jetbrains.com/issue/IJPL-177161/Modal-commi...
Recently joined a new team where I have to use VS because we have to work through a remote desktop where I can't install new stuff without a lengthy process, and having used VS for a while now it's so much worse. I miss Rider practically every second I'm writing code. There is nothing that I need that VS does better, it's either the same or usually worse for everything I do.
I hope I'll get a bit more used to it over time but so far I hate it. Feels like it's significantly reducing my velocity compared to Rider.
If it really must be, VSCode for everything else.
I never was a JetBrains fan, especially given the Android Studio experience, glad that is no longer a concern.
IntelliJ is the best there is for Java, warts and all.
Quite curious of the answer in such great IDE.
Now on team Zed. We’ll see how long that is good before it enshittifies too. I’m not sure if I should be happy they’re still not charging me for it.
They’re one of the few products that just amazes me with how robust it is. Often, it will tell me I have issues before I even know about them (e.g my runtime is incorrect) and offer 1-click fixes.
They learned from the best: Microsoft.
Microsoft cannot fix bugs because it's "engineers" are busy rounding corners in UI elements.
And support teams don't fix bugs?
The issue becomes, you have two teams, one moving fast, adding new features, often nonsensical to the support team, and the second one cleaning up afterward. Being in clean-up crew ain't fun at all.
This builds up resentment, i.e. "Why are they doing this?".
EDIT: If you make it so support team approval is necessary for feature team, you'll remove autonomy from feature team, causing resentment in their ranks (i.e. "Why are they slowing us down? We need this to hit our KPIs!").
Team A does majority of new features in major release N.
Team B for N+1.
Team A for N+2.
Team A maintains N until N+1 ships.
Team B maintains N+1 until N+2 ships.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.
So unless you are overworking (e.g., you work in your jira tasks AND on top of that you fix bugs) I don’t see it.
I would love to work on things that make sense like stabilising the system and all, but I work on whatever sells or whatever the EM/PM wants. These days unfortunately, shipping >>> fixing.
I recognize this isn't true in organizations where everything is micromanaged, work time is tracked in hours or even minutes, and autonomy doesn't exist.
The more the employees are treated like responsible professionals, the more this is possible. And conversely, the more they're like factory workers behind a conveyor belt, the less this is possible.
Obviously 'fake Agile' is an industry wide problem here. But if teams cannot control their capacity expectations, it will always devolve to this
'slack' was a poor term to use IMHO, but it is here.
In companies that care about med/long term survival and success can fix this over time.
Selling it as derisking on strategic and initiative time scales is one way that can help.
How do you incentivise developers to put that slack to good use? In my experience, without an incentive, culture slowly rots to the point where the majority of developers simply don't.
And if you're _always_ in deadline mode, I'd argue you have a bigger problem.
2. Merge the resulting fix in as part of another MR
3. In the unlikely event anyone questions you, say that you needed to make changes in that area anyway, and it'll reduce the support burden.
I don't say this to scold you, but I think most of us should keep in mind that even simple code changes incur risk and add testing requirements.
I've worked in places where I was forbidden to fix bugs. Even if it was 1 line adjacent to the code I was editing.
The boss there used to work at amazon. I guess it wasn't a simple coincidence.
We are Agile now. Continous "improuvment". /s
It's a lot easier when you're not shoving out a release every 2 weeks. When I worked at a company with quarterly releases, the standing order was fix any bug you see and we saw drastic improvements after just a few releases.
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 userbase is different, in a small saas company you will probably get fairly "high signal" complaints, this is not true for mass market products.
Fixing bugs is different, sometimes you need to cross 3 teams in different timezones and have a bunch of meetings to fix a bug. Often the real problem is that a business process or a legacy system is messed up and an individual dev is not going to have the political "swing" to be able to do anything about it.
Big companies are typically structured to limit the agency of ICs.
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".
I don't want to start a company, find funding money, hire developers, develop a go-to-market strategy, A/B test, pivot, pivot again, and eventually maybe release a product or maybe just get bought out.
I just want to be able to right-click and/or highlight some text in my child's school's communications app.
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.
3 is sometimes given lip service, but ultimately the only way 3 ever gets done is if someone in upper management pretends to care that 3 is important. Which is pretty rare
4 also happens but everyone thinks they are skunkworks engineer even when they are not
I’ve also encountered several “load bearing bugs” where subsequent integrations/workflows were designed to accommodate the bug. Sometimes this was because the bug was known but couldn’t be fixed at the time, or the developers assumed the program was working correctly and accommodated the bug thinking it was expected behavior.
Therefore fixing the original bug would raise questions about what else needs to be updated as well.
5. Fixing a bug means you have to go through a re review of your marketing assets that haven't changed in 3+ years and there's a non zero chance each time your review could result in _your app being removed from the storefront_ and losing _days_ of revenue after you appease whatever whimsical issue wasn't an issue the hundreds of times you've submitted previously and wait for the next review slot.
We of course fix the serious issues, but we also leave a lot of bugs collecting virtual dust in our tracker.
While I know our customers get annoyed with bugs, they care a lot more about essential features and low price.
Now, we're in the process of incrementally rewriting our 20+ year old software, and code quality has a very high priority now. So hopefully the future will be brighter.
That said, our users are incredibly good at finding weird issues.
If a company's ultimate goal is to extract money from people, then developers who can extract money faster (even if their rendering/loading algorithms suck) will get rewarded better than those who don't.
That's why enshittification is a thing (and actually come to think of it, not new either). It might be a dev that learned from product leadership that, "I could fix these 13 lines of code. But you know, our company could also sell a 'PRO' version subscription for $5 a month which provides the fix..."
The goal is to write not-bad code. You're not trying to do shoddy work on purpose but good enough is good enough.
There's a reason way more people buy furniture from IKEA than some craftsman who loves woodworking.
People also don't generally pay the premium for craftsmanship in clothing, house construction, vehicles, food ....
Lots of development shops care about UX/DX. Many Indie games are crafted with love and often many are successful -- even releasing bug fixes and updates years after it entered the shop on steam. Many high level developers learned how to write good code quickly, not just for themselves, but for the people that came after them.
If presented with a good argument, most people will agree to logic. Unfortunately, many business decisions are made behind closed doors to avoid dissent -- or even any discussion of alternatives.
There is no substitute for actually providing value at the end of the day.
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.
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.
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.
This is a consequence of developers who never use anything but Mac and don't even realise this is wrong. Which is especially egregious for a product that an overwhelming majority of their customers will only ever see on Windows.
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.
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.
The article isn't arguing that "companies don't fix bugs" universally, rather it is explaining, in cases when they don't fix bugs, why they did not do so.
Sort of like if you saw an article about job searching titled "Why Employers Don't Respond"
I genuinely can't tell what this means. How is it different from "Why (Companies Don't Fix Bugs)"?
"X don't Y" generally means "X never Y" (ex: "Grapes Don't Grow On Trees").
However, adding Why to the front of X Don't Y ("Why X Don't Y") does not necessarily mean "X Don't Y. Why?" - rather, sometimes it's actually asking "In cases when X do not Y, why not?"
In other words, you can't necessarily parse the sentence by simply parsing "X Don't Y" by itself and then applying "Why" as a question to that. That was what I was trying to illustrate.
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.
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 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.
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.
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 guess the concept wasn't paying off because the team was disbanded, as was the forum we used to communicate directly with our customers.
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.
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.
I got tired of this and grabbed a couple other devs and split up the jira bug backlog between us, and we started closing out dupes and non-repro tickets, after about two days and thousands of tickets closed my manager angrily came over to my cube and demanded I stop because "it was making the company look bad".
Sometimes the best option is not to play.
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.
Loading times over 6 minutes for 1/3 of the playerbase (according to a poll linked in the original post about that bug) are not hard to quantify, that's disastrous. Many people would simply quit and play something else at that point.
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".
" 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
Many are saying this...
Also this article reads like AI slop particularly the "Why Good Bugs Go Unfixed" section.
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.