I worked on the Photos team a decade ago — some of what you're saying I can vouch for. If it is a rare occurrence, that lowers the priority of the bug. Data corruption though? That moves it to the top.

I'll tell you a secret though that kind of pisses me off. If you have shipped with a bug, that automatically lowers the perceived priority as well. You know, as opposed to introducing a new bug in a new release. "We've already lived with that old bug…" seems to be the mind set. Oh well.

To be sure though, if you saw the number of bugs that queue up for a popular app like Photos, you'd know that fixing all of them is not going to be possible — some kind of system of prioritization is required.

▲

crote 7 days ago | parent | next [-]

> if you saw the number of bugs that queue up for a popular app like Photos, you'd know that fixing all of them is not going to be possible

Why? If your app is used by billions of people, surely you can afford a few additional testers and engineers? Your app doesn't have an unlimited number of bugs: if you are solving them faster than you are introducing them, the number of bugs will eventually approach zero.

Sure, you'll always have newly-introduced bugs which are still waiting to get fixed, but if you've got an ever-increasing pile of bugs which have been around for years - even when they have been reported with easy-to-reproduce steps - then something has gone horribly wrong with your development process. At a certain point you have to stop shoveling new crap, rethink the workflow which is introducing so many new bugs, and slowly start fixing old bugs. The alternative is that your code will inevitably degrade into 100% bugs and become completely unusable and unmaintainable.

	▲	jmb99 7 days ago \| parent \| next [-]
		> Why? If your app is used by billions of people, surely you can afford a few additional testers and engineers? Unfortunately, in the real world, # of bugs solved per unit time does not scale linearly with # of developers - and, you eventually reach enough people that you can't effectively coordinate changes without wasting more time on processes than you're gaining by adding another person. I've never worked at Apple and I don't know anyone on the Photos team, but I imagine a company at that scale probably has a good idea as to the optimal number of developers working on one application. Optimal to Apple probably involves optimal money spent:money earned ratio, not most bugs fixed per unit time, but I would wager those numbers are pretty similar anyways.
	▲	yummypaint 7 days ago \| parent \| prev [-]
		Garbage software still makes lots of money. Sometimes more than good software, and certainly more than the best software. Just look at the windows vs Linux ecosystem for a simple task like screen recording with decent compression. Open source tools are superior, but can be harder to even find on windows due to the poorer signal/noise ratio from all the terrible for profit/enshittification software. Some graphics drivers have dashboards that do screen recording, but that is not a universal solution. The most viable free options on windows seem to be sketchy cloud stuff designed to be inconvenient enough to upsell you. On Linux it's either built in already or trivial to install something that records locally and doesn't rug pull the user demanding money.

▲

ryandrake 7 days ago | parent | prev | next [-]

> I'll tell you a secret though that kind of pisses me off. If you have shipped with a bug, that automatically lowers the perceived priority as well. You know, as opposed to introducing a new bug in a new release.

This mentality is all over BigTech: This bug didn't block release X-1, why should it block release X? So, it inevitably just sits in the backlog forever. If your releases are 90 days apart, any bug found has an average of 45 days to be fixed, or it ends up on the "we lived with it last time" list.

	▲	throwaway31131 7 days ago \| parent [-]
		If you have more bugs than you can fix in a given amount of time then you have to prioritize somehow. “This bug didn't block release X-1, why should it block release X?” Is actually a pretty strong argument and tough, but not impossible, to counter. And the bug backlog only gets longer with time. It’s the price of greatly increased software complexity.

▲

egorfine 7 days ago | parent | prev | next [-]

Yeah, I have had friends in Apple and they have described pretty much the same approach. It's perfectly understood.

There is one more thing that gets factored into the bug triage. If the bug affects professional users (as in, data corruption from external media) - fuck them. Apple couldn't care less about professional users. The priority is to fix Photos.app for utility gauge pics and preferably in HEIC and other default settings.

▲

AceJohnny2 7 days ago | parent | prev [-]

> If you have shipped with a bug, that automatically lowers the perceived priority as well.

This is unfortunately still true. I've had some radars de-prioritized with this exact reason and there are few things more infuriating.

It's really a sign of an overwhelmed, dysfunctional organization, but I heard from an ex-CoreOS guy that that's an intentional management choice, "people perform better under pressure"... (although I'm guessing Photos is not in the CoreOS org)