Good interview as usual on Failory. He posts lots of them on Barnacl.es, too. Gotta poke at this: "On the other hand, no software is perfect and if somebody sa

Good interview as usual on Failory. He posts lots of them on Barnacl.es, too. Gotta poke at this: "On the other hand, no software is perfect and if somebody says, their software is bug-free, they are lying." Strawman to dismiss folks who argue for high-quality software. If they think it doesn't exist, they probably didn't know about Cleanroom Software Engineering and Praxis' Correct-by-Construction: http://infohost.nmt.edu/~al/cseet-paper.html http://infohost.nmt.edu/~al/cseet-paper.html http://www.anthonyhall.org/c_by_c_secure_system.pdf http://www.anthonyhall.org/c_by_c_secure_system.pdf There's a difference between accidentally being buggy because the problem is that hard and intentionally leaving it buggy for faster iterations. They're doing the latter. Which is fine in their situation. They could probably adopt some proven approaches to increase their QA results on the cheap, though. Easiest route is some slice of design/code reviews plus contracts (esp pre-conditions) with contract/property-based testing and fuzzing. Catches all kinds of problems.