Software Engineering Code of Ethics and Professional Practice
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:
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.
IEEE-CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practices (version 5.2)
Showing posts with label Profession. Show all posts
Showing posts with label Profession. Show all posts
Thursday, October 15, 2009
Software Engineering Code of Ethics and Professional Practice
Following is the short "preamble" version of the IEEE-CS and ACM endorsed Software Engineering Code of Ethics and Professional Practice (also found on the online ethics site, as a PDF, and at the ACM site):
Saturday, August 22, 2009
On Professionalism: Welcome to the Family
I've always maintained the necessity of creating a true, organized profession out of software development/engineering and computer science. One aspect of making that a reality is creating a unified "family". Sadly, the lack of professionalism and unified identity is keeping some from joining our profession and encouraging those already in it to leave. David Alan Grier in his article "Welcome to the Family" [1] writes:
If we want to encourage others to join our profession, or those in it to remain, we most make sure he/she "finds value in our companionship."
References
[1] Grier, David Alan, "Welcome to the Family" in IEEE Computer, Volume 42, Issue 8, 2009
Computer science has generally felt more comfortable with families of technology than with families of professionals.
professional life ... [involves] discipline, loyalty, competition, common knowledge. It [is not] something that [can] be turned into a desirable activity with some fun and games. Becoming a professional means joining the family, with all the rights, responsibilities, and discipline that come with membership.
The field of computer science is defined not only by technical accomplishments but also by those who take the name of computer scientist. As has happened in the past, and as will likely happen in the future, we are seeing both researchers and practical innovators question the value of identifying themselves with our discipline. Their answers will largely depend on whether they think we have anything to offer them.
We might see a rise in membership if we offered vengeance for a child wronged, but we are more likely to be successful if we can offer an identity that promises a better and exciting future.
If we want to encourage others to join our profession, or those in it to remain, we most make sure he/she "finds value in our companionship."
References
[1] Grier, David Alan, "Welcome to the Family" in IEEE Computer, Volume 42, Issue 8, 2009
Friday, July 10, 2009
The Manifesto for Software Craftsmanship
I came across the following well intentioned manifesto the other day. Quote:
The manifesto is a concise set of ideals all practicing professional software developers should follow. I also suggest adhering to the IEEE-CS and ACM endorsed Software Engineering Code of Ethics and Professional Practice (also found on the online ethics site, as a PDF, and at the ACM site), perhaps even more so, given the status of these organizations. The short form (i.e. preamble) is:
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:The above is quoted from The Manifesto for Software Craftsmanship. Dr. Dobb's Agile Update 03/09 describes the above in more detail, and also the Agile Manifesto, from which it is derived.
- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration, but also productive partnerships
The manifesto is a concise set of ideals all practicing professional software developers should follow. I also suggest adhering to the IEEE-CS and ACM endorsed Software Engineering Code of Ethics and Professional Practice (also found on the online ethics site, as a PDF, and at the ACM site), perhaps even more so, given the status of these organizations. The short form (i.e. preamble) is:
Software Engineering Code of Ethics and Professional Practice
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:
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.
IEEE-CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practices (version 5.2)
Saturday, February 21, 2009
Business Analysis, Software Engineering, and Our Profession
At the insistence of my employer I completed a Business Analysis course in gathering and documenting user
requirements. I expected from the title and description it was about gathering business requirements, which in
my mind are high level requirements expressed in business terms about how a solution (which may or may not
include a software system) to a business problem should fit with the business goals, address business needs,
and bring value to the organization. As there was no hint of software engineering in the course description, I
was thinking this course could not be about software (or systems) requirements engineering I first learned in
school and practiced for years.
I was wrong.
A rough guess: 90% of the material was straight from classical software engineering requirements elicitation and documentation courses taken in university. I was thinking while sitting through this course: Is most of this stuff not simply a part of software engineering? Why the silly name Business Analysis, like it is a distinct profession outside the domain of software engineering? And, how can a class full of software developers not know this stuff already? What kind of education do they have? Where did they do their training to become software developers and not learn this stuff? Disturbingly, many in this course have been building software for years and are calling themselves software developers.
I suspect many "software developers" lack other software engineering fundamentals as well. Consider the core courses for a certificate in Business Analysis: How to Gather and Document User Requirements, Testing for Business Analysts, Object Orientation for Business Analysts, and Object Oriented Modeling. These are topics all software developers should be intimately familiar with. Obviously, some of us are not. But why not?
I believe the answer lies in the lack of a professional organization that certifies (and licenses?) software engineers. Such an organization would ensure quality engineers by mandating appropriate education, training, and experience, and establishing codes of ethics and professionalism. Even though a lot of software is built to run critical systems (think about software in the medical, engineering, banking, and insurance fields, to name a few), we do not have any regulations on who is qualified as a software engineer to build such systems; i.e. there is no regulatory body to ensure those who practice our profession are qualified to do so. In the words of Bjarne Stroustrup: "I find it appalling that you can become a programmer [software engineer] with less training than it takes to become a plumber" [1].
The lack of required and approved software engineering training has resulted in many developers having little or no requirements elicitation and documentation knowledge (not to mention other software engineering fundamentals). This is a fundamental part of the software engineering process, and many in our profession are not prepared to do it. What has resulted is a need in the business world to fill a void created by inadequate and under qualified software developers. Hence, Business Analysts, out of necessity, have expanded their role to do what good Software Engineers should be doing.
My understanding from this course is that Business Analysts are gaining evermore respect in our field and are leading the way to certification on their own. Good for them. If we as a group of software development professionals (software engineers, computer scientists, programmers, and the like) can't organize ourselves and bring some professionalism to our discipline, more and more of our field will be shifted to other professionals who can. I can see this already happening. The Business Analyst is now somehow seen as much more than the Software Engineer, fulfilling major roles in the software engineering process (I'm not saying BAs don't have a role to play, just not as software engineers). That leaves us as "just coders", unprofessional worker bees, with no control over our own profession. Shame on us.
Every true profession eventually forms an organization to ensure integrity and quality of the professional, and to protect the public, the business world, and the practitioners. Such organizations also ensure the discipline remains in practitioner's hands and those practicing it are properly qualified (education, certification, licenses). Consider teachers, lawyers, doctors, pharmacists, electricians, and, my God, in my neck of the woods even mortgage brokers. They have all professionalized. Its time we grow up and do the same.
References
[1] James Maguire, Bjarne Stroustrup on Educating Software Developers, Datamation, http://itmanagement.earthweb.com, 2008
I was wrong.
A rough guess: 90% of the material was straight from classical software engineering requirements elicitation and documentation courses taken in university. I was thinking while sitting through this course: Is most of this stuff not simply a part of software engineering? Why the silly name Business Analysis, like it is a distinct profession outside the domain of software engineering? And, how can a class full of software developers not know this stuff already? What kind of education do they have? Where did they do their training to become software developers and not learn this stuff? Disturbingly, many in this course have been building software for years and are calling themselves software developers.
I suspect many "software developers" lack other software engineering fundamentals as well. Consider the core courses for a certificate in Business Analysis: How to Gather and Document User Requirements, Testing for Business Analysts, Object Orientation for Business Analysts, and Object Oriented Modeling. These are topics all software developers should be intimately familiar with. Obviously, some of us are not. But why not?
I believe the answer lies in the lack of a professional organization that certifies (and licenses?) software engineers. Such an organization would ensure quality engineers by mandating appropriate education, training, and experience, and establishing codes of ethics and professionalism. Even though a lot of software is built to run critical systems (think about software in the medical, engineering, banking, and insurance fields, to name a few), we do not have any regulations on who is qualified as a software engineer to build such systems; i.e. there is no regulatory body to ensure those who practice our profession are qualified to do so. In the words of Bjarne Stroustrup: "I find it appalling that you can become a programmer [software engineer] with less training than it takes to become a plumber" [1].
The lack of required and approved software engineering training has resulted in many developers having little or no requirements elicitation and documentation knowledge (not to mention other software engineering fundamentals). This is a fundamental part of the software engineering process, and many in our profession are not prepared to do it. What has resulted is a need in the business world to fill a void created by inadequate and under qualified software developers. Hence, Business Analysts, out of necessity, have expanded their role to do what good Software Engineers should be doing.
My understanding from this course is that Business Analysts are gaining evermore respect in our field and are leading the way to certification on their own. Good for them. If we as a group of software development professionals (software engineers, computer scientists, programmers, and the like) can't organize ourselves and bring some professionalism to our discipline, more and more of our field will be shifted to other professionals who can. I can see this already happening. The Business Analyst is now somehow seen as much more than the Software Engineer, fulfilling major roles in the software engineering process (I'm not saying BAs don't have a role to play, just not as software engineers). That leaves us as "just coders", unprofessional worker bees, with no control over our own profession. Shame on us.
Every true profession eventually forms an organization to ensure integrity and quality of the professional, and to protect the public, the business world, and the practitioners. Such organizations also ensure the discipline remains in practitioner's hands and those practicing it are properly qualified (education, certification, licenses). Consider teachers, lawyers, doctors, pharmacists, electricians, and, my God, in my neck of the woods even mortgage brokers. They have all professionalized. Its time we grow up and do the same.
References
[1] James Maguire, Bjarne Stroustrup on Educating Software Developers, Datamation, http://itmanagement.earthweb.com, 2008
Subscribe to:
Posts (Atom)