Software Engineering Code of Ethics and Professional Practice by the ACM and the IEEE-CS

Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

Short :

1. PUBLIC - Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.
3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.
4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment.
5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.
6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.
7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

Detailed Information

Principle 1: PUBLIC

 Software engineers shall act consistently with the public interest. In particular, software engineers shall, as appropriate:

• Accept full responsibility for their own work.
• Moderate the interests of the software engineer, the employer, the client and the users with the public good.
• 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.
• Disclose to appropriate persons or authorities any actual or potential danger to the user, the public, or the environment, that they reasonably believe to be associated with software or related documents.
• Cooperate in efforts to address matters of grave public concern caused by software, its installation, maintenance, support or documentation.
• Be fair and avoid deception in all statements, particularly public ones, concerning software or related documents, methods and tools.
• Consider issues of physical disabilities, allocation of resources, economic disadvantage and other factors that can diminish access to the benefits of software.
• Be encouraged to volunteer professional skills to good causes and contribute to public education concerning the discipline.

Principle 2: CLIENT AND EMPLOYER

Software engineers shall act in a manner that is in the best interests of their client and employer, consistent with the public interest. In particular, software engineers shall, as appropriate:

• Provide service in their areas of competence, being honest and forthright about any limitations of their experience and education.
• Not knowingly use software that is obtained or retained either illegally or unethically.
• Use the property of a client or employer only in ways properly authorized, and with the client's or employer's knowledge and consent.
• Ensure that any document upon which they rely has been approved, when required, by someone authorized to approve it.
• Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law.
• Identify, document, collect evidence and report to the client or the employer promptly if, in their opinion, a project is likely to fail, to prove too expensive, to violate intellectual property law, or otherwise to be problematic.
• Identify, document, and report significant issues of social concern, of which they are aware, in software or related documents, to the employer or the client.
• Accept no outside work detrimental to the work they perform for their primary employer.
• Promote no interest adverse to their employer or client, unless a higher ethical concern is being compromised; in that case, inform the employer or another appropriate authority of the ethical concern.

Principle 3: PRODUCT

Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. In particular, software engineers shall, as appropriate:

• ·         Strive for high quality, acceptable cost and a reasonable schedule, ensuring significant tradeoffs are clear to and accepted by the employer and the client, and are available for consideration by the user and the public.
• ·         Ensure proper and achievable goals and objectives for any project on which they work or propose.
• ·         Identify, define and address ethical, economic, cultural, legal and environmental issues related to work projects.
• ·         Ensure that they are qualified for any project on which they work or propose to work by an appropriate combination of education and training, and experience.
• ·         Ensure an appropriate method is used for any project on which they work or propose to work.
• ·         Work to follow professional standards, when available, that are most appropriate for the task at hand, departing from these only when ethically or technically justified.
• ·         Strive to fully understand the specifications for software on which they work.
• ·         Ensure that specifications for software on which they work have been well documented, satisfy the users’ requirements and have the appropriate approvals.
• ·         Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates.
• ·         Ensure adequate testing, debugging, and review of software and related documents on which they work.
• ·         Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project on which they work.
• ·         Work to develop software and related documents that respect the privacy of those who will be affected by that software.
• ·         Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized.
• ·         Maintain the integrity of data, being sensitive to outdated or flawed occurrences.
• ·         Treat all forms of software maintenance with the same professionalism as new development.

Principle 4: JUDGMENT

Software engineers shall maintain integrity and independence in their professional judgment. In particular, software engineers shall, as appropriate:

• ·         Temper all technical judgments by the need to support and maintain human values.
• ·         Only endorse documents either prepared under their supervision or within their areas of competence and with which they are in agreement.
• ·         Maintain professional objectivity with respect to any software or related documents they are asked to evaluate.
• ·         Not engage in deceptive financial practices such as bribery, double billing, or other improper financial practices.
• ·         Disclose to all concerned parties those conflicts of interest that cannot reasonably be avoided or escaped.
• ·         Refuse to participate, as members or advisors, in a private, governmental or professional body concerned with software related issues, in which they, their employers or their clients have undisclosed potential conflicts of interest.

Principle 5: MANAGEMENT

Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance . In particular, those managing or leading software engineers shall, as appropriate:

• Ensure good management for any project on which they work, including effective procedures for promotion of quality and reduction of risk.
• ·         Ensure that software engineers are informed of standards before being held to them.
• ·         Ensure that software engineers know the employer's policies and procedures for protecting passwords, files and information that is confidential to the employer or confidential to others.
• ·         Assign work only after taking into account appropriate contributions of education and experience tempered with a desire to further that education and experience.
• ·         Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work, and provide an uncertainty assessment of these estimates.
• ·         Attract potential software engineers only by full and accurate description of the conditions of employment.
• ·         Offer fair and just remuneration.
• ·         Not unjustly prevent someone from taking a position for which that person is suitably qualified.
• ·         Ensure that there is a fair agreement concerning ownership of any software, processes, research, writing, or other intellectual property to which a software engineer has contributed.
• ·         Provide for due process in hearing charges of violation of an employer's policy or of this Code.
• ·         Not ask a software engineer to do anything inconsistent with this Code.
• ·         Not punish anyone for expressing ethical concerns about a project.

Principle 6: PROFESSION

Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. In particular, software engineers shall, as appropriate:

• ·         Help develop an organizational environment favorable to acting ethically.
• ·         Promote public knowledge of software engineering.
• ·         Extend software engineering knowledge by appropriate participation in professional organizations, meetings and publications.
• ·         Support, as members of a profession, other software engineers striving to follow this Code.
• ·         Not promote their own interest at the expense of the profession, client or employer.
• ·         Obey all laws governing their work, unless, in exceptional circumstances, such compliance is inconsistent with the public interest.
• ·         Be accurate in stating the characteristics of software on which they work, avoiding not only false claims but also claims that might reasonably be supposed to be speculative, vacuous, deceptive, misleading, or doubtful.
• ·         Take responsibility for detecting, correcting, and reporting errors in software and associated documents on which they work.
• ·         Ensure that clients, employers, and supervisors know of the software engineer's commitment to this Code of ethics, and the subsequent ramifications of such commitment.
• ·         Avoid associations with businesses and organizations which are in conflict with this code.
• ·         Recognize that violations of this Code are inconsistent with being a professional software engineer.
• ·         Express concerns to the people involved when significant violations of this Code are detected unless this is impossible, counter-productive, or dangerous.
• ·         Report significant violations of this Code to appropriate authorities when it is clear that consultation with people involved in these significant violations is impossible, counter-productive or dangerous.

Principle 7: COLLEAGUES 

Software engineers shall be fair to and supportive of their colleagues. In particular, software engineers shall, as appropriate

• ·         Assist colleagues in professional development.
• ·         Encourage colleagues to adhere to this Code.
• ·         Credit fully the work of others and refrain from taking undue credit.
• ·         Review the work of others in an objective, candid, and properly-documented way.
• ·         Give a fair hearing to the opinions, concerns, or complaints of a colleague.
• ·         Assist colleagues in being fully aware of current standard work practices including policies and procedures for protecting passwords, files and other confidential information, and security measures in general.
• ·         Not unfairly intervene in the career of any colleague; however, concern for the employer, the client or public interest may compel software engineers, in good faith, to question the competence of a colleague.
• ·         In situations outside of their own areas of competence, call upon the opinions of other professionals who have competence in that area.

Principle 8: SELF

Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. In particular, software engineers shall continually endeavor to:

• ·         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.
• ·         Improve their ability to create safe, reliable, and useful quality software at reasonable cost and within a reasonable time.
• ·         Improve their ability to produce accurate, informative, and well-written documentation.
• ·         Improve their understanding of the software and related documents on which they work and of the environment in which they will be used.
• ·         Improve their knowledge of relevant standards and the law governing the software and related documents on which they work.
• ·         Improve their knowledge of this Code, its interpretation, and its application to their work.
• ·         Not give unfair treatment to anyone because of any irrelevant prejudices.
• ·         Not influence others to undertake any action that involves a breach of this Code.
• ·         Recognize that personal violations of this Code are inconsistent with being a professional software engineer.

This Code was developed by the ACM/IEEE-CS joint task force on Software Engineering Ethics and Professional Practices (SEEPP)

Tips for Enjoying the Software Development

 

The Enjoyable Profession of Software Development

Software development can be a tremendously rewarding, enjoyable career.
Few careers offer comparable opportunities to weave intricate, complex structures that, while virtual, have such a positive impact on the world around them. Few offer the freedom and creativity that software development does, or the very real potential for entrepreneurial riches.
Whether it's building a new peer-to-peer application, control software for a massive power generator, or improving the workflow of the corporate scorecard system, done right this can be a very fulfilling, enjoyable, challenging pursuit.

A Passion for Software Development?

Are you really passionate about software development? Be honest with yourself.
A desire to outshine a teammate isn't passion. Nor is a motivation to impress the boss. Neither is a combination of the two worn as a magic defensive cloak against downsizing spells. These are second-rate, artificial passion substitutes: Mixed into the recipe, they yield sub par results, often leaving a nasty aftertaste of burnout and dissatisfaction.
Instead I'm talking about a bona fide interest and enjoyment of the craft and challenge of software development, even outside of career or job security issues (though it benefits the same). This isn't a job ad demanding that you're "passionate about business reports!", but rather is just a moment for sober reflection on whether you're over-clocking life, or running idle instructions in a tight loop.
If you're like many software developers in the industry today, a feeling of enthusiasm and enjoyment for the pursuit is just a distant memory (often during the happy days of university and your first job). Instead it has become a career, and is just something you do from 9-5 (or more when passion is replaced by sacrifice). Skills have likely stagnated, moving just enough to compete with coworkers, or to avoid obsolescence.
Of course there are those who've never enjoyed this career, and they probably will never enjoy it -- it just isn't their thing. The only advice I can offer to those people is a suggestion that life is too fleeting to spend so much time doing something you don't enjoy.

Software developers who truly love what they are doing are the ones creating the most innovative code. They're the ones with productivity rates multiples of their peers. They're the ones that feel a little guilty getting paid to do something they enjoy so much

The Tips to be a  Productive, Happy Software Developers

1. Be Marketable - Keep Up To Date Skills and Network Contacts

Most of us will work for over a dozen different firms over our careers.
We'll leave for better salaries and working conditions. We'll relocate to accommodate a spouse's career. We'll be laid off during corporate mergers and spin-offs, or even when the company goes bankrupt. We'll get turfed out because we're over-skilled, and thus overpaid, relative to the needs of the position. We'll be downsized because we aren't compatible with the new boss' empire building schemes. Maybe we'll get bored of a position and seek out something new.
This is the employment reality of most careers in the 21st century.
To some professionals this represents an exciting journey, and each transition is met with anticipation and enthusiasm. These people feel confident in their abilities, have a network of peers in the industry communicating interesting opportunities, and their skillset is up-to-date and marketable (they have the appropriate laundry list of abilities, credentials and certifications, and upgrade as needed), and while the possibility of their current employer closing shop tomorrow is something they'd prefer not happen, and they probably love the great group of people that they work with, it isn't something that they fear.
To less prepared professionals, however, the idea of losing their cushy job hangs over them like a black cloud. Their lack of apparent opportunities, and the feeling that they couldn't find an equivalent job, is enormously destructive of both motivation and job satisfaction. Paradoxically, job protectionism (such as making one "indispensable" through obscurity, by denigrating coworkers, and so on) often becomes a more likely activity of people in such positions than legitimate contributions.
This is incredibly destructive to morale, not just for the individual in question, but for everyone on their team: Often the malcontent, contagiously demotivated member of the team is the least employable, and it can be debated which condition led to the other.
SUMMARY:  No matter how much you love your current job, you should keep your CV current, and you should always keep up-to-date on industry opportunities. Know what skills are in demand, and try to gain experience in them (even if it means pursuing formal or self-training during your own time), and attain a level of comfort that you could transition to a different opportunity with minimal discomfort.
MANAGER SUMMARY: You should do everything in your power to make your group feel confident in their abilities -- ensure that everyone gets a chance with marketable technologies; encourage the pursuit of desirable certifications; and build skills through internal resources, workshops, and seminars. Unless you're running a sweatshop, this is unlikely to lead to a feared exodus of employees, but instead will empower and motivate your group to more openly contribute, and to demand more of each other.

2. Be The Master of Your Domain

The control we have over our environment can have a tremendous impact on our happiness.
Something as simple as a sporadically malfunctioning key on our keyboard can ruin an entire day, for instance. Similarly, when you're nearing a deadline and your network connection starts flaking out, it can make an enjoyable jog to the finish line a frustrating exercise of physical restraint (in this case restraining yourself from tearing the wiring out of the wall). At least we have optical mice now, eliminating one of the primary causes of environmental control frustration.
Many times our work habits inevitably bring a feeling of "lack of control" into our work lives: By failing to fully read the documentation for our tools, investigating their behaviour, APIs, and nuances, we often create a situation where much of our development is basically crap-shoot trial and error, reacting as things don't work as planned.
I've witnessed development groups, not to mention that I've demonstrated this unsavoury trait myself, unhappily fighting with perceived technology deficiencies (usually as a deadline rapidly approaches), moaning and complaining about what seems to be faults in the language, technology, or platform, forever building workarounds under a fog of uncertainty, when in reality it was actually a fault in the understanding of the same.
More often than not it's simply that they haven't spent the upfront time to understand the language (I remain amazed at the number of C# developers who have no idea what the using keyword is for, or why seemingly out-of-scope file objects are still locking files until some magical, indeterminate time in the future. Or the Delphi developers who needlessly nulled variables at the end of scope in a futile misguided attempt to fight mystery bugs), the technology, or the platform. Their frustration is created out of ignorance, and a small up-front investment would have sped up development, increasing the sense of control that the developers have over their domain.
SUMMARY: The next time something seems mysterious or unknown, take the time to properly investigate it. Classic lack-of-control approaches such as hacked workarounds or "reset the server daily" lead to a feeling of losing control, reducing job satisfaction and adding to the natural daily frustrations. And get your keyboard replaced if it starts malfunctioning.
MANAGER SUMMARY: Identify and investigate "easy-outs" proposed by your development team. While most software has faults, and products and technologies often work differently than we might imagine, many times such excuses are due to a lack of investigation and analysis. Even when things don't work as advertised, which is frequently the case, formally investigating and empirically determining behaviours is vastly superior to each developer endlessly fighting with and then hashing out strategies on a need basis. And make sure your developers have functioning keyboards.

3. Accommodate Your Financial Needs

I've worked in some great positions at the wrong times in my life, sapping my motivation until eventually I moved on. These positions were for great firms, with great working conditions and great coworkers and management, but it couldn't realistically adapt to accommodate my evolving financial needs. I invented dissatisfactions with the situation, turning an ideal situation into a daily torture.
After getting married and planning for our first child, for instance, the financial risk/reward that worked when I was living alone in a $600 apartment eating Ramen noodles was no longer satisfactory. Demands of owning a home, a car with infant carseats, education funds, daycare (for two children costing more than it would cost to lease two (2) BMW 750i's), and boxes and boxes of diapers, required more financial returns than I needed years before.
I moved on.
While the resulting role superficially wasn't as satisfactory, from a life perspective my mood brightened dramatically, and my day was much more enjoyable.
Of course this seems like cheap advice: Make more money! And Fast! Yet the reality is that developers often do make choices to the detriment of their financial condition, and if they go too far they will hate their job no matter how perfect it otherwise is. Working for equity of a start-up is great when you're just out of university, but it is destined for failure when you're more established.
SUMMARY: If your financials are out of balance, it will unavoidably sour your mood during the workday, making you resent your employer and your workplace. When life goals exceed the income of your position, immediately begin investigating alternatives (be it asking for a raise, looking for a more senior role in your organization, or seeking employment elsewhere). No motivational boost or cool company games room will overcome this basic life need.
MANAGEMENT SUMMARY: Be aware of the goals and needs of your group. Sometimes someone's needs grow beyond the possible return of a position, and it is important to appropriately communicate this (rather than giving vague hints of unseen raises and super-bonuses at some future point).

4. Have A Life Outside of Work

This is a rule that works for all professions -- having accomplishments providing satisfaction outside of work will smooth the inevitable downs of our professional lives, often providing one with a much better perspective. Without this, often minor workplace failures can explode into seemingly momentous events.
These accomplishments can even be in the same domain: A professional coder by day, and an open-source coder by night, for instance.
SUMMARY: There will be periods when everything seems to go wrong in the workplace. Having the cushion of achievements outside of work can avoid it spiraling into a workplace disaster, keeping spirits up through the tough times. Often non-work experiences benefit the workplace as well, whether it's techniques learned from nighttime projects, or delicious coffee courtesy of the nighttime barista classes.
MANAGER SUMMARY: There is a world outside of work.

5. Properly Manage Expectations

Developers, as a general rule, are terrible at managing expectations: Many of us are prone to overpromising deliverables, assuring stakeholders that we'll deliver these amazing results sooner than is reasonable. I've fallen victim to this syndrome myself, and I've seen it occur rampantly across the industry.
When D-day comes we convince ourselves into believing that the users built their own unrealistic expectations, and managers forced us into untenable timelines. While often that is the case, just as frequently the developers were the origin of misinformation.
While there is a temporary sense of satisfaction wowing users and management with an exaggerated declaration of our abilities (we've likely even convinced ourselves), as time wears on this misinformation can be enormously destructive and debilitating. With every day closer to the deadline we get a little more desperate for a silver bullet, hoping that some magic technology or component will deliver us from damnation.
It seldom works out that way.
Users are unhappy. Management is dissatisfied. Employees are demoralized and devastated.
The best option is always to manage expectations, to ensure that we can reasonably deliver promised results without heroic effort.
SUMMARY: Plan for the long term, realizing that promises that aren't delivered on will cause you great workplace unhappiness later. Manage expectations to ensure that you can satisfy your "customers" with reasonable effort, and with a reasonably high probability of success.
MANAGER SUMMARY: Never demand unrealistic deadlines, and question employees when provided with the same. Encourage your troops to be more reasonable with their promises, especially to stakeholders outside of the group, and they'll have a much greater probability of meeting external expectations, leading to increased motivation for everyone.

Conclusion

This is an amazing, expansive career full of incredible innovation and endless opportunity. Ensure that you don't diminish your enjoyment through simple mistakes, such as pigeon-holing into a position, or endlessly setting up yourself for failure.