4 ms·

> 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

> 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.

meatmanek 13y ago
> 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. For many cases of software development, just keeping your ethical principles in the back of your mind as you work should be enough. A formal study and report of the ethical considerations of your work is not necessary. However, there are certainly cases where a more formal review would be appropriate - generally high-impact/high-cost-of-failure cases, e.g. the electrical grid, car/plane control systems, or systems that deal with money or private information. In a lot of these cases, there exist legal or professional standards that apply, such as PCI, SOX, or HIPPA. Those standards are made of more specific guidelines than this code of conduct, but they generally follow the same themes. They also generally require independent review and certification that you're following the rules, so in these cases, formal reports are already the norm. There's a spectrum. Near one extreme of the spectrum, your client/employer is going to be happy to see two weeks down as 'Corporate Social Responsibility Report - £6k', or something similar.

meatmanek 13y ago

> 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. For many cases of software development, just keeping your ethical principles in the back of your mind as you work should be enough. A formal study and report of the ethical considerations of your work is not necessary. However, there are certainly cases where a more formal review would be appropriate - generally high-impact/high-cost-of-failure cases, e.g. the electrical grid, car/plane control systems, or systems that deal with money or private information. In a lot of these cases, there exist legal or professional standards that apply, such as PCI, SOX, or HIPPA. Those standards are made of more specific guidelines than this code of conduct, but they generally follow the same themes. They also generally require independent review and certification that you're following the rules, so in these cases, formal reports are already the norm. There's a spectrum. Near one extreme of the spectrum, your client/employer is going to be happy to see two weeks down as 'Corporate Social Responsibility Report - £6k', or something similar.