|
|
|
|
|
by crote
270 days ago
|
|
> 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. |
|
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.