Been there done that. A real solution would be to stop hiring new developers, to reduce the size of the current dev team, to reduce the size and responsibility of the QA team in order to force developers to test their own code. To eliminate any new feature requirements, to prioritze regression testing (migration, update, etc) and to allocate a whole release to trim the pile of bugs in radar.
Why Apple can’t do that? 1. Pressure from investors “we want to see new stuff”. 2. If they stop hiring new “talents” that would benefit other companies including competitors. 3. You can’t hire good developers and ask them to fix bugs for a year because they would run away from you which would compromize 1. And 2.
It is a tough problem for Apple it ain’t easy to fix. In other words, Apple needs a Steve Jobs. It needs to focus and disconnect from the world for a little while no matter the short term consequences. If you’re confident enough you’re doing the right thing for your customers, it’ll pay off in the long run.
> You can’t hire good developers and ask them to fix bugs for a year because they would run away from you
Really? I've never experienced that in the workplace. However, I'm not that widely travelled and not in SV, so I guess I'd be "unsurprised but depressed" to learn that this degree of idiotic entitlement is common. And idiotic is exactly what it is: truly quality software is the product of lots and lots of bugfixing. It's like the "10% inspiration/90% perspiration" thing, but for initial development and bugfix/gradual improvement work. Especially on huge (OS-sized) software, people hiring on should not be surprised that this is the bulk of their day-to-day.
I get that greenfield development is more fun up front. I just (perhaps naïvely) hope that most professionals understand that a) "fun" and "good for the product" aren't the same thing, and b) that it can also be very personally rewarding to spend a long time fixing bugs (yours or others') and see the quality of/user happiness with a product noticeably increase.
Also, I think being able to say "I fix bugs to maintain an operating system used by millions" is at least as rewarding as being able to say "I make buggy websites for startups whose marketing buzz reaches millions".
I think we're on the same page. I was simply highlighting things I witnessed from my past experience. Bugs (in Mac OS) get really nasty sometimes and frustrating for the most part. It is brain consuming and the reward isn't always worth the energy spent. Management doesn't even reward bug fixing unlike the "new" stuff. Ask any dev from that specific team (or even iOS team) to fix bugs for a whole year and you'll see the reaction. Some actually do because of a "lower" global performance at work. You can easily get assigned on bugs over "new" stuff if you don't hustle 24/7 but that's a whole new topic :)
But to add up to my previous comment - only a few people get to implement new stuff each year, they don't test their code and fall under very tight deadlines, so they produce buggy stuff. This generates tones of new bugs constantly tracked by QA (QA doesn't fix anything, they just report problems), bugs quickly pill-up in Radar and developers are already assigned onto something else. Most of the bugs reported by customers are duplicates... they're usually already tracked, either not assigned yet or simply lower priority than something else. So what it the problem? Well, everything I mentioned ;)
I think we agree as well; my reply was meant to speculate on whether anti-maintenance sentiment comes from developers or higher up (culture etc.).
> Management doesn't even reward bug fixing
I think that's the moral of the story. It's not that developers are childish, stamp their feet, and refuse to do bugfix work; it's that they're incentivized to not do it.