Are you saying they should have extra people doing code review - requires two instead of 1 (I don't know the number, but assume that's the norm). Or more rigorous testing technique? I am all for it. Is this something they can easily discover through automated testing?

The vp of engineering should have invested in a good static analysis tool which would have spotted this section in about five seconds. Failing that turning on a sensible set of defaults in the compiler (warning about unreachable code) would have also drawn attention to it.

There are many many ways this should have been caught before it even left the building by numerous automated tools. Heck most modern IDEs will flag unreachable code in the editor so there is no real excuse for this. (Adding -Wunreachable-code to a sample project in Xcode immediately flags the next line).

The programmer is human which is why automated verification tools exist.

(AppCode's default inspections will also flag the issue providing you run them)

I'd be really really surprised they didn't run this through static analysis. I will, to be honest, then maybe people are right about "it's stupid they make such stupid mistake."

I am not familiar with running static analysis and looking output, only did very minimal undefined behavior santisizer detection.

I haven't been keeping up, but a year ago Google wasn't using any static analyzer at all on Chrome. They didn't use a real memory access checker like valgrind even to load a blank page, although they came up with a weaker memcheck that mostly works.

Lax development is par for the course at these mega corps.

We've been using valgrind bots for a long time on the Chromium project - certainly for much longer than a year.

For example, according to the Wayback Machine, our sites page had an entry about it since 2009:

http://web.archive.org/web/20091123132855/http://www.chromiu...

I was thinking of this:

http://www.reddit.com/r/programming/comments/mw2sn/googles_a...

I cannot comment on Chrome itself, but internal C++ development at Google has a pretty comprehensive array of checks, both static and dynamic.

having extra people doing code review risks something that happens with physical products.

You take the experienced people off the shop floor, and call them inspectors. So now the quality of product coming off the shop floor is worse.

Ann is the first inspector in the chain. When she's busy (and remember, she will be because quality has dropped) she might be tempted to let a few things go because Bob, the second inspector in the chain, is bound to catch them. That's what he's there for.

Bob is the second inspector in the chain. Sometimes Ann really churns the product through. Luckily during those busy times he knows she's already inspected the stuff, so he only needs to give a 10% inspection.

So you have worse product with more errors and leaky inspection.

Ideally you'd have a system with skilled workers and self inspection. That's okay for aerospace (which pays well) but not so great for lower cost product.

Not quite sure how this transfers to coding.

Okay. Good point but I hope if people take the job seriously they will have to be very careful. Though that's ideal..

How about this:

owner/peer of the module has to sign off, and randomly select two more. One must be QA and one is another programmer who works on the module. We can also pick a "junior" level, but then that's probably not going to work since Apple employes programmers who have some years of experience already. Or we can pick someone who isn't directly working on that module, but have some qualification to do review. Mostly just asking "why are you having two goto, why return -100 here)

But I see counterargument: they will just listen to the author if he's senior or the owner who is also a senior. Their words carry weight.

That's assuming they are full time at inspection, another scenario is where one person does it in addition to their current responsibilities. Therefore the overall quantity of what's produced is reduced but the inspection levels are higher.