Hacker News Reader

Comment by taylodl | Hacker News Reader

What Apple, and Microsoft before them, are discovering is the tools and processes we use to create software simply doesn't scale. We're simply reaching the limits of what these giant software teams are able to produce and keep running. We can discuss solutions, but currently not everybody even agrees we have a problem. That's the first step we need to take.

View on HN

I disagree that this is the product of scale. Looking at some of the bugs coming out of Apple lately and how they respond to them (assuming it's really a trend and not just a run of bad luck) it feels like they're slipping into a culture where individual feature teams are making emotional or schedule-based decisions about security without central guidance. A good example is the recent bug on MacOS where a low-privileged user could kill other users' processes and reboot the machine, but allegedly this wasn't considered a security problem. It doesn't seem like they have a core part of their organization that drives security practices and knows how to triage and give guidance on these issues, because if the bug had been escalated to a group like that, it would certainly have gotten some traction. It would be nice to hear an insider's take on it...

Within the context of the previous comment, this is a great comment.

I read it six times in rapid succession and it keeps flipping between being a supporting arguement for and against the parent comment.

I like to call that a blue/white rebuttal

Is this a reference to something I'm not familiar with?

It's probably a reference to the debate on Reddit about whether a dress (http://i.imgur.com/9VWYggm.jpg) was black and blue or white and gold.

Some bugs are so bad it begs the question if they even test at all, such as the iMessage Apps store favorites bug a few iOS releases ago.

I run iOS public betas. The staggering improvement in quality between beta 1 and beta 7 seems to be evidence that they doing largely effective QA of major “happy paths.” What I do find interesting is that in early betas, things are broken that imply there are either constant fundamental rewrites going on, or that architecture is sloppy. (Hope it’s the former.) After the final betas, the remaining bugs seem to be untested edge cases. Of course, with complexity, there’s a combinatorial explosion of edge cases to test, so it’s likely their QA is constantly being outpaced.

You're just making assumptions. All we know is that there's a failure.

We don't know what kind of and how many errors triggered the failure, nor do we know what the faults causing the errors were.

We certainly don't know what kind of hazard analysis they did and what kind of mitigations they have in place, nor do we know whether they accepted a specific amount of residual risk for e.g. economic or market pressure reasons.

We don't know what kind of QC they do.

Without this information, it's pointless to talk about how things feel or seem. This is a very large engineering organization, working on a very large and complex system. It's not possible to find the root cause (or any cause) of a failure by using guesswork or by reporting to familiar failure cases.

> Without this information, it's pointless to talk about how things feel or seem.

Au contraire! Without this information we can only talk about how things feel or seem.

Au contraire yourself. Your statement that this is the only thing we can talk about, does not contradict the assertion that talking about it is pointless.

Remind me not to invite you to parties ;)

Remember not to invite me to parties.

Exactly. One can discuss and imagine all they want without full information and it's very normal and socially and personally productive. I'd refrain from issuing final judgements unless you have "all the info" but that's pretty obvious.

One can gossip about Apple's technical problems, but it's neither interesting nor a good use of the time of most of the people on HN I'd imagine.

I don't see how that's productive, what has been "produced" here? Even the reddit comment from an (alleged) Apple employee was contradicted by other (alleged) Apple employees.

Gathering any insights into Apple's quality issues does not seem to be possible at all from internet comments... that makes the whole thing misleading and pointless to me.

I was speaking in a slightly more general sense. I mean what can we as humans do then? Just shut up and go on our way? I don't necessarily disagree that there isn't much of tangible value to be gained for us, but I don't think it's useless to discuss these scenarios. Hopefully it helps us human inform future decisions we may all have to make one day, and if people talk about problems enough they have a way of becoming acknowledged.

Or we can not talk and save everyone some time.

> where a low-privileged user could kill other users' processes

Incorrect. A low-privileged user can kill their own processes, which is the expected behavior of kill(-1). The only issue is the fact that this can apparently also kernel panic the machine. But the fact that it kills all the processes belonging to the user is the expected behavior of this call.

Bingo. The entire system including the software, hardware, people, customer demands and market pressures, (lack of) regulations has become too complex to handle by humans.

These repeated errors looks like classic system or normal accidents as defined by Perrow in his book.

part of me is wondering if this is just a case of showing the limits of the current "developers can do qa" development model.

I do think a lot of these issues could be easily caught before shipment by having a well paid adversarial QA department, but at the same time it is easy to see why this is not done, despite all the griping on tech websites about code quality going down all across the board everywhere, it's not like people will stop buying iphones etc. so it's an easy ROI decision to continue with the "users are QA" mindset.

Waiting for everyone to agree seems like a very futile and inefficient way to achieve progress.

That's true, but critical mass is more important than consensus and we're not close to that either.

The solution is silod shared-dependency-free APIs (even if that means a duplicated code base across APIs [storage is cheap]) and micro refactoring.

We've started on this path with Apps, we just need to lock it in with an open source OS that is simply a userdata securing app store.

Reply on news.ycombinator.com