3 ms·
"Ethics" when taught as part of a professional education usually relates to professional ethics as encoded by codes of practice. While certainly related to mora
by ajarmst 9y ago
"Ethics" when taught as part of a professional education usually relates to professional ethics as encoded by codes of practice. While certainly related to morality, legality, religious ethos, humanism, etc. professional ethics shouldn't be conflated with them. As a case in point, I doubt that many would argue that American lawyers and businesspeople are, as a group, noticeably more moral actors than computer programmers, despite the benefit of that additional training.
Moral behaviour is the concern of a society, not merely of a profession. If we are concerned that actors in important sectors of our economy are behaving immorally, our first thought shouldn't be to blame the CS curriculum, as though three credits of pondering "Eve knows they're faking the test results for QA, but her shares vest in 30 days" would fix the problem.
Rather, I think what might be needed is the development of a stronger sense that IT development should be a professional pursuit, in the sense of a community of practice that holds itself to a high standard, and has governing bodies that will enforce that standard. That is, it may be time to treat developers the way we treat doctors, lawyers and engineers. (Of course, many already are engineers, and thus already have a code of practice and the requisite three credits of "dilemma of the week" studies.)
- rocqua 9y agoThe profession is currently growing too quickly for any such community to form. Any such community is going to exclude some people (the immoral ones). As morality and competency at programming aren't that strongly correlated, those people are still going to be able to find work. Attempts to limit this by regulation will constrict supply of labour so much it'll never pass. Arguably, it should never pass.
- ajarmst 9y agoThere's probably a tighter labour market for physicians, yet no one claims we should de-regulate their standards of professional practice. And, while morality and competency may not be correlated, ethics and quality certainly are. Codes of practice invariably include clauses around providing quality work, guarding the best interests of your client, avoiding conflicts of interest, obeying pertinent regulations and laws, etc. And it need not be the entire profession: in Engineering, technicians and technologists often do much of the work, but the product cannot ship without an Engineer (who is governed by a code of practice and faces a variety of sanctions for violating it) signing off on it. Simply adding that sort of requirement for public contracts, FCC sign off, etc. would go a long way to enforcing a code. Advancement beyond a certain level would require that you meet the training and experience standards of the profession. Again, we already do this with lots of professions (including Software Engineering in some jurisdictions)---pretending that it somehow couldn't be done for developers needs better evidence than anything I've yet seen. Of course you can always buy cheaper products from non-professionals. You can do that with medicine and product safety already. And you get precisely what you pay for.
- rocqua 9y agoThere isn't much of a market for unlicensed medical help. There'd be a market for unlicensed coders. Anyone can write up a piece of code, and plenty of people can do it sufficiently well to be useful commercially. Moreover, there is tremendous growth in this area, most plans for economic growth these days centers around tech innovation. Taking that away is going to meet strong resistance. Finally, this either kills open source or leads to very very weird grey lines. Besides that, drugs and buildings are well-defined products. Software gets weird, how do you apply rules to SaaS? How does sign-off interact with continuous delivery? Who is held accountable when a hardware bug causes a software error? What about an OS bug, or malformed packets? I agree that we need regulation and accountability here, but blanket engineer-like requirements aren't going to work. Both because the actual requirement is hard to implement, and because there is such a glut for programmers. The second might blow over, but the first is an eternal issue. Maybe requiring well limited fitness for purpose statements from engineers on critical cases can work.