4 ms·

You are put in charge of Apple. How do you fix this?

pducks32 9y ago
Using an iPhone X only proves to me that Apple engineers make incredible software that just work....when they want to. The app switching on iPhone X is perfect bc there was probably a team on that. The problem isn’t new stuff it’s old stuff. Like is there a team just working on Disk Utility or maybe just one dude who checks iOS and macOS for date/time problems. They need a few more people.
- heartbreak 9y ago
  I thought we had all decided that throwing more people at a software problem isn’t a viable solution.
  - Aaargh20318 9y ago
    This isn’t one software problem, it’s a shitload of software problems.
  - reificator 9y ago
    Throwing more people at a software problem isn't a viable solution to meet a deadline. Obviously there is benefit to adding more people, it's just that that benefit takes time to offset the cost of onboarding. Communication does place an upper limit on the number of people who can work on a specific project, and later the total number of projects that can interact. Something exploratory like what what the GP was suggesting doesn't require huge teams or a lot of interaction between teams, at least until the problems are identified and need to actually be resolved.
  - coldtea 9y ago
    That's only if we're talking about a single codebase. Throwing more people at different programs, where they are needed, e.g. some to work on Mail.app, some to work on a better Calendar, some to work on Pages, etc, is a totally viable solution.
  - deleted 9y ago
    [deleted]
jccalhoun 9y ago
I hear on podcasts that apple likes to keep their teams small. I know throwing money at software problems doesn't fix things but they have enough money that they could hire some more people. (disclaimer, I don't actually use any Apple products at the moment.)
newsbinator 9y ago
The trick seems to be convincing your best engineers to work on unsexy products that have long lifetimes. Everybody would rather spearhead the new iPhone XI project, than spearhead the "add 10% to the battery life on 4-year old MacBooks" project. You'd need an incentive program to offset fame/pride. For example, "150% pay for working on non-sexy projects" or "additional points for tangible improvements or bug fixes to legacy code".
- virgilp 9y ago
  > You'd need an incentive program Also called "salary increases", "promotions" and "bonuses". Not just for the people who do the sexy new projects. Because let's face it - you're being rewarded far better in a corporation for releasing something new, than for fixing something old. And keeping something old working perfectly with no issue? Well, nobody hears about you, so probably you're not doing anything, you're lucky if you're not fired. (I'm exaggerating, of course; but unfortunately, not much)
- mamcx 9y ago
  Or reframe the attitude that suport your loyal customers is bad.
Aaargh20318 9y ago
Release software when it’s done, instead of when the yearly release deadline passes.
- rorykoehler 9y ago
  This is something I'm introducing in my company. Teams sticking to dates for releases for no apparent reason other than it's the date scheduled makes zero sense.
  - mikestew 9y ago
    Ya know, I remember snarking asking in triages, “so are we quality-driven or date-driven?”, with the assumption being that any idiot would of course want to be quality-driven. And now you’re telling me companies explicitly choose “date-driven, please”.
ratsimihah 9y ago
Make it a #1 priority, QA test the shit out of it, release a proper fix, apologize and move on.
thsowers 9y ago
Bring back a dedicated Mac operating system team that they got rid of in 2016 [0] [0]: https://www.bloomberg.com/news/articles/2016-12-20/how-apple-alienated-mac-loyalists https://www.bloomberg.com/news/articles/2016-12-20/how-apple...
dilap 9y ago
Create a Mac QA division that gets to decide when the release is ready. Make sure that any public bugs like the root login bug are specifically tested to not regress. For security things, specifically have people who's goal it is to try to break into the computer. If the extra QA ends up slipping the release date of Mac, fine. Better to slip a date than ship software which breaks users and erodes trust. Unlike some other commenters, I don't see this as so much of an engineering issue. Bugs are bugs and inevitable; at the end of the day, to ship quality software you have to test it. That's what's missing here. (Not to say that good engineering practices can't make it easier to reach that quality bar, or that very bad engineering practices can't make it impossible [whack-a-mole phenomenon], but that doesn't seem to be Apple's problem here.)
- virgilp 9y ago
  > Bugs are bugs and inevitable; at the end of the day, to ship quality software you have to test it No. Testing can never ever hope to give you bug-free products.... coding discipline and relentless pursuit of simplicity in design can. The question is not why the testers didn't catch the "root with no password" bug - the question is really how it was possible to have it, in the first place.
  - dilap 9y ago
    I disagree. Coding discipline and relentless pursuit of simplicity are great things, but there's no amount of discipline or simplicity that is going to save you completely from bugs. You've got to test. Even mathematical proofs are often found to have errors; even formal methods will have errors in the specification.
    - virgilp 9y ago
      I don't say testing is useless, but it's highly unlikely that Apple doesn't test at all. From a point on, extra testing won't help you. I kinda doubt that the main problem here was "not enough testing"
      - 9y ago
addicted 9y ago
Don’t enforce an arbitrary annual release cadence. More public beta testing. Have canary branches that users can install on a regular basis.

Using an iPhone X only proves to me that Apple engineers make incredible software that just work....when they want to. The app switching on iPhone X is perfect bc there was probably a team on that. The problem isn’t new stuff it’s old stuff. Like is there a team just working on Disk Utility or maybe just one dude who checks iOS and macOS for date/time problems. They need a few more people.

heartbreak 9y ago
I thought we had all decided that throwing more people at a software problem isn’t a viable solution.
- Aaargh20318 9y ago
  This isn’t one software problem, it’s a shitload of software problems.
- reificator 9y ago
  Throwing more people at a software problem isn't a viable solution to meet a deadline. Obviously there is benefit to adding more people, it's just that that benefit takes time to offset the cost of onboarding. Communication does place an upper limit on the number of people who can work on a specific project, and later the total number of projects that can interact. Something exploratory like what what the GP was suggesting doesn't require huge teams or a lot of interaction between teams, at least until the problems are identified and need to actually be resolved.
- coldtea 9y ago
  That's only if we're talking about a single codebase. Throwing more people at different programs, where they are needed, e.g. some to work on Mail.app, some to work on a better Calendar, some to work on Pages, etc, is a totally viable solution.
- deleted 9y ago
  [deleted]

jccalhoun 9y ago

I hear on podcasts that apple likes to keep their teams small. I know throwing money at software problems doesn't fix things but they have enough money that they could hire some more people. (disclaimer, I don't actually use any Apple products at the moment.)

newsbinator 9y ago

The trick seems to be convincing your best engineers to work on unsexy products that have long lifetimes. Everybody would rather spearhead the new iPhone XI project, than spearhead the "add 10% to the battery life on 4-year old MacBooks" project. You'd need an incentive program to offset fame/pride. For example, "150% pay for working on non-sexy projects" or "additional points for tangible improvements or bug fixes to legacy code".

virgilp 9y ago
> You'd need an incentive program Also called "salary increases", "promotions" and "bonuses". Not just for the people who do the sexy new projects. Because let's face it - you're being rewarded far better in a corporation for releasing something new, than for fixing something old. And keeping something old working perfectly with no issue? Well, nobody hears about you, so probably you're not doing anything, you're lucky if you're not fired. (I'm exaggerating, of course; but unfortunately, not much)
mamcx 9y ago
Or reframe the attitude that suport your loyal customers is bad.

Aaargh20318 9y ago

Release software when it’s done, instead of when the yearly release deadline passes.

rorykoehler 9y ago
This is something I'm introducing in my company. Teams sticking to dates for releases for no apparent reason other than it's the date scheduled makes zero sense.
- mikestew 9y ago
  Ya know, I remember snarking asking in triages, “so are we quality-driven or date-driven?”, with the assumption being that any idiot would of course want to be quality-driven. And now you’re telling me companies explicitly choose “date-driven, please”.

ratsimihah 9y ago

Make it a #1 priority, QA test the shit out of it, release a proper fix, apologize and move on.

thsowers 9y ago

Bring back a dedicated Mac operating system team that they got rid of in 2016 [0] [0]: https://www.bloomberg.com/news/articles/2016-12-20/how-apple-alienated-mac-loyalists https://www.bloomberg.com/news/articles/2016-12-20/how-apple...

dilap 9y ago

Create a Mac QA division that gets to decide when the release is ready. Make sure that any public bugs like the root login bug are specifically tested to not regress. For security things, specifically have people who's goal it is to try to break into the computer. If the extra QA ends up slipping the release date of Mac, fine. Better to slip a date than ship software which breaks users and erodes trust. Unlike some other commenters, I don't see this as so much of an engineering issue. Bugs are bugs and inevitable; at the end of the day, to ship quality software you have to test it. That's what's missing here. (Not to say that good engineering practices can't make it easier to reach that quality bar, or that very bad engineering practices can't make it impossible [whack-a-mole phenomenon], but that doesn't seem to be Apple's problem here.)

virgilp 9y ago
> Bugs are bugs and inevitable; at the end of the day, to ship quality software you have to test it No. Testing can never ever hope to give you bug-free products.... coding discipline and relentless pursuit of simplicity in design can. The question is not why the testers didn't catch the "root with no password" bug - the question is really how it was possible to have it, in the first place.
- dilap 9y ago
  I disagree. Coding discipline and relentless pursuit of simplicity are great things, but there's no amount of discipline or simplicity that is going to save you completely from bugs. You've got to test. Even mathematical proofs are often found to have errors; even formal methods will have errors in the specification.
  - virgilp 9y ago
    I don't say testing is useless, but it's highly unlikely that Apple doesn't test at all. From a point on, extra testing won't help you. I kinda doubt that the main problem here was "not enough testing"
    - 9y ago

addicted 9y ago

Don’t enforce an arbitrary annual release cadence. More public beta testing. Have canary branches that users can install on a regular basis.