> Did you even read the bullet points? None of them are about writing perfect code or non-buggy code.

A: I don't appreciate insults with a question mark stuck after them.

B: While they don't tell you how to write non-buggy code many of the points clearly relate to code quality:

"1.03. Approve software only if they have a well-founded belief that it is safe, meets specifications, passes appropriate tests, and does not diminish quality of life, diminish privacy or harm the environment. The ultimate effect of the work should be to the public good."

Safe, meets specifications, passes appropriate tests. In other words, isn't buggy. Bugs are just behaviour that doesn't meet the spec, software that meets the spec but doesn't do what you want is poorly designed - i.e. the spec is wrong. Indeed one can advance a meaningful argument that as long as it meets the spec, software is never fixed, it's simply redesigned.

"3.01. Strive for high quality, acceptable cost and a reasonable schedule"

High quality. What would you call a piece of code with bugs in it? Low quality, one would rationally assume.

"3.10. Ensure adequate testing, debugging, and review of software and related documents on which they work."

Adequate testing, debugging. The purpose of tests is to make sure that you meet the spec across the expected input space without producing undesired behaviour - any deviation from this is a bug. Debugging - well, heck - that's directly in there.

"6.03. Extend software engineering knowledge by appropriate participation in professional organizations, meetings and publications."

Okay, so this one doesn't strictly speaking bear on bugs alone. Still writing non-buggy software should be the natural consequence of it and it fits with the theme established in the rest of the document to do with quality of code. I don't think I've met any knowledgeable programmers who write buggy code.

"6.08. Take responsibility for detecting, correcting, and reporting errors in software and associated documents on which they work."

Errors in software, aka bugs.

"7.04. Review the work of others in an objective, candid, and properly-documented way."

As with 6 not solely concerning bugs but doubtless relating to them at least partially.

"8.01. Further their knowledge of developments in the analysis, specification, design, development, maintenance and testing of software and related documents, together with the management of the development process."

Maintenance and testing. Okay, that could relate to performance, but one rather hopes you're catching any bugs that might be in there too.

"8.02. Improve their ability to create safe, reliable, and useful quality software at reasonable cost and within a reasonable time."

Reliable software, i.e. software without bugs. Heck, however poor your software is in terms of efficiency and user interface, if it has no bugs then it's at least reliable - it keeps to the contract in the spec.

> You can if that's part of your process. You do plan things out before you work right?

To an extent. A client is not gonna be super-happy to see two weeks work down as 'Corporate Social Responsibility Report - £6k' on their invoice though. Nor is your boss, if you work in a team, liable to be pleased when you tell them to wait two weeks while you make sure they're not telling you to do evil.