[ANU] [DCS] [COMP2100/2500] [Description] [Schedule] [Lectures] [Labs] [Homework] [Assignments] [COMP2500] [Assessment] [PSP] [Java] [Reading] [Help]
COMP2100/2500
Lecture 28: PSP IVSummary
Commitment management and related issues.
Aims
Introduce and discuss the idea of making responsible commitments.
Discuss some of the broader issues raised.
Commitment management
“As long as we do not change our habits,
we will continue to make the same mistakes.”
Commitments are more than contracts.
They involve a personal decision or agreement.
Can't be done by coercion.
Must be individual choice, balanced against other commitments such as family, personal growth, ambitions, lifestyle choices etc.
How to make responsible commitments
Analyse the task in depth. Be sure that you will be able to meet the commitment.
Document the agreement in writing.
Make a plan for meeting it.
If you can't meet it, say so.
Failure to meet commitments
In software engineering, typically results from engineer not making a personal commitment. (This can be a conscious choice.)
If you are going to fail to meet a commitment, own up sooner rather than later.
Delaying in the hope that things will improve usually makes them worse.
If you keep doing the same thing, expect to get the same result.
Consequences of not managing commitments
Work exceeds time available.
Failure to meet commitments.
Misplaced priorities.
Poor quality work.
Loss of trust.
Others lose respect for your judgement.
More commitment managment tips
If you are falling behind, do something different, or you will just get further behind.
Trying harder won't help. (You're already trying as hard as you reasonably can. Unless your level of motivation or interest changes, your level of effort won't either.)
Know where you are up to.
Don't rely on luck.
Wrong estimates of time needed are usually too low.
Further Thoughts
This is really about taking responsibility:
for your work
for your life
PSP is a framework around which to organise that, in the specific area of software development.
It is only one of many ways to do it, and indeed it seems to me to be a particularly mechanistic, anti-humanistic way.
For other viewpoints on taking responsibility for the software development process, read:
Peopleware by DeMarco & Lister
Quality Software Management Volumes 1-4 by Gerald Weinberg
Going Deeper
Thinking about the various approaches to software development, about trying to become systematic, about looking at the process and trying to improve quality and productivity raises several questions for me:
Why?
What is software for?
Who benefits from software?
In general?
In particular instances?
Should programmers take responsibility for the software they write, beyond questions of how well-written it is and whether it is done on time?
Is it OK just because you're paid to do it?
Would you be comfortable working on:
Software to guide missiles to their targets?
Software to link all government and corporate databases, enabling the state to monitor people's lives in incredible detail?
Software to provide encrypted distribution of child pornography or terrorist plans, safe from detection by law-enforcement agencies.
Software to control industrial robots that will do the work of thousands of workers, putting them out of jobs but increasing corporate profits.
Software projects that are funded by taxpayers' money and that you know will fail.
Professional Ethics
We have two main areas of professional responsibility:
Towards our employer, a narrow sort of professionalism: "Do the job well."
Write quality software: few defects, satisfy requirements, reliable, usable etc.
Must be produced on time and on budget. (This involves time and commitment management.)
We also have a much broader responsibility to understand and protect the public interest, the environment, our society, the world.
This is not just because death and destruction are bad for business (although they certainly are).
If we don't do it voluntarily, it will eventually be legislated for us, and that might have other unfortunate consequences (like killing the open source movement perhaps).
It's just basic morality. It's also about whether you can live with yourself. (See above.)
Who Can Write Software?
Absolutely anyone!
Would this be tolerated in other professions?
No. Think of medicine, engineering, dentistry, psychology, nursing, social work, even food preparation in restaurants. People need certification or registration or a licence. But not in software.
Who should write software? (Or put it the other way around: who would you buy software from?)
Someone who has:
appropriate training;
appropriate experience;
up-to-date knowledge; and
a sense of ethics.
In other words, a certified member of a professional society.
Major Professional Societies in Software
ACS: The Australian Computer Society http://www.acs.org.au/
ACM: The Association for Computing Machinery http://www.acm.org/
IEEE: The Institute of Electrical and Electronics Engineers http://www.ieee.org/
IEEE Computer Society http://www.computer.org/
IEAust (Engineers Australia) http://www.ieaust.org.au/. (They accredit our Bachelor of Software Engineering degree.)
The ACS and the IEEE Computer Society have certification programs.
Codes of Ethics
The IEEE and ACM have codes of ethics for computer professionals. See also
The Ten Commandments of Computer Ethics from the Computer Ethics Institute.
Here are some selected items from the ACM and IEEE Codes of Ethics, and the Ten Commandments of Computer Ethics.
- ACM 1.2:
Avoid harm to others.
- ACM 1.6:
Give proper credit for intellectual property.
- ACM 1.7:
Respect the privacy of others.
- ACM 2.6:
Honour contracts, agreements, and assigned responsibilities.
- IEEE 1:
Accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment.
- IEEE 3:
Be honest and realistic in stating claims or estimates based on available data.
- IEEE 6:
Maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations.
- IEEE 7:
Seek, accept, and offer honest criticism of technical work, acknowledge and correct errors, and credit properly the contributions of others.
- CEI 9:
Thou shalt think about the social consequences of the program you are writing or the system you are building.
[ANU] [DCS] [COMP2100/2500] [Description] [Schedule] [Lectures] [Labs] [Homework] [Assignments] [COMP2500] [Assessment] [PSP] [Java] [Reading] [Help]
Copyright © 2005, Ian Barnes & Jim Grundy, The Australian National University
Version 2005.2, Monday, 30 May 2005, 14:54:16 +1000
Feedback & Queries to
comp2100@cs.anu.edu.au