In university, I did a co-op job with a civil avionics shop where I learned all about DO-178B, the standard by which avionics software is certified. DO-178B Level A-certified is top-quality and highly reliable. I feel safe flying on planes after working in that industry. It's a rigourous process, and software that emerges from it basically never fails.
But it's an expensive and slow process to develop software this way, and it's prone to failure from any number of reasons. Requirements and technology change, and must be known up-front. Capital can run dry.
It's only worthwhile developing software this way when absolutely necessary, when half-working software is dangerous and could kill someone.
That being said, I do think he has a good point with desktop and webapps where you can quickly get and act on feedback from the customers.
He isn't talking about fast iterations. He is talking about feeling responsibility about what you are delivering, instead of using procedures as a crutch. I know I would rather fly in a plane that had its sowftware written by developers that cared about their work than by "engineers" that don't think about their work because they expect the code review and a couple of QA cycles to catch all the bugs.
[1] http://en.wikipedia.org/wiki/Iron_Ring (It's a Canadian thing.)
That's one of the coolest things I've heard in quite some time. Perhaps software engineers in the US should wear some visible reminder of "Microsoft Bob"?
http://en.wikipedia.org/wiki/Engineer%27s_Ring http://en.wikipedia.org/wiki/Order_of_the_Engineer