NASA's Software Assurance Technology Center at Goddard once did a test to see how few defects they could get in some code for the shuttle. After a truly rigorous and vastly, vastly expensive process, with multiple levels of review, using very small functions to minimize the risk in each, they managed to get it down to 1 defect per 10,000 lines of code (might've been 100k, I forget). This is, to this day, held as the most defect-free code ever written.
Their ultimate decision was that this mode of software production was not useful or usable to anyone on the planet: they couldn't write all their code like this, nor even all their mission-critical code, and even after the huge financial and time investment in perfectionism, they only managed to reduce the defects, not eradicate them.
In fact, they never again developed code to this standard, as it simply was not economical.
[Edit: I am wrong.I am wrong. In comments, @Benjaminssp provides a link ( http://www.fastcompany.com/28121/they-write-right-stuff) showing that the SATC has continued in its efforts towards zero-defect code, and has achieved an error rate that looks to be about 2 errors per MLoc2 errors per MLoc - this is frankly mindblowing to me, but they show that it can be achieved! However, I feel my point still stands, though greatly weakened: even NASA cannot get complete freedom from defects.]
So: if you attempt to reassure a developer that their software is 100% defect free, then the developer will typically ask for another QA person. The best you can say is "Your code performs to spec, for the inputs we have tested it with, which achieved 100% code coverage... assuming our tests are correct."
Always remember that your testing code itself will have a few defects per thousand lines.