Hacker News Reader

Comment by rosstex | Hacker News Reader

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

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...

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.

I thought we had all decided that throwing more people at a software problem isn’t a viable solution.

This isn’t one software problem, it’s a shitload of software problems.

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.

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.

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.)

> 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.

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.

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"

I'm sure they test some, & you might well be right, but to me, from the outside, it mostly seems like a failure to test thoroughly that's their main problem.

E.g., the root-login-bug slipping back in is inexcusable. That bug should've entered in a "make sure this doesn't" regress list and be tested every release. Yet, it wasn't.

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".

> 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)

Or reframe the attitude that suport your loyal customers is bad.

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

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.

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”.

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.)

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

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

Reply on news.ycombinator.com