Best Practice and Best Behavior
| Although each of these scenarios, which are based on real occurrences in Australian companies in the past three months, might appear to be an isolated example, they are in fact common everyday facts of life for many information system people. In 1996 we did a road show for the Australian Computer Society on computer ethics and we discussed these and similar scenarios with more than 1,000 Australian, Hong Kong, U.S., and New Zealand business and system people. A significant majority of these people agreed that these types of situations are common events and they felt that such behavior is justified in most cases. These situations are not just examples of poor management practices, but a clear indication of a deeper problem ”a lack of ethical standards. Most project groups are undertaking serious reviews of the current levels of service, practice, productivity, and costs associated with information system development and support. Many of these reviews are being undertaken by external consultants at significant expense and effort. The typical outcome of these reviews includes recommendations on the following:
What these reviews generally fail to understand is that there is a long-established and undocumented set of values and attitudes (in essence, a culture) within the computing groups that can and do undermine attempts to improve computing group productivity and service. As discussed in Chapter 1, these values and attitudes have evolved throughout the 30 years of commercial computing. They are passed on by senior computer people to new entrants through a combination of actions and other specific but undocumented practices. For example, most junior programmers have been taught an almost mythical rule of estimation: Derive your estimate, double it, and then add 30% for contingency. This informal culture is further enforced through a lack of effective project and quality management procedures, management training, cost measurement, and accountability that is widespread in computing groups. These values and attitudes, which experts such as Maddux and Maddux (1989) and Henderson (1992) agree define a code of ethics, have produced an environment in which the situations described earlier can happen without any examination or concern. Indeed, as described by Bhide and Stephenson (1990) and many others, the high incidence of major corporate fraud and unethical behavior during the 1980s and 1990s has led to a corporate environment in which any professional, business or computer, must be cynical about the whole issue of ethical behavior. In simple terms, when you see business behaving unethically, it's easy to justify your own unethical behavior. This situation is particularly deplorable when so many of the computing concepts and approaches are drawn from other professions that all have well-established codes of ethics and associated disciplinary procedures for breaches of ethical behavior. For example, the term software engineer reveals computing wishes to adopt the technical practices and disciplines of engineering without adopting the formal codes of ethics associated with the engineering professions. In another example, project management is another computing term that has been adopted from a professional management body (i.e., the Australian Institute of Project Management) with a published code of ethics and disciplinary procedures. It is true that the Australian and British Computer Societies and other professional IT bodies [2] have a published code of ethics, but the majority of computer people are not members of a professional body. For business project people, there is no support at all.
In a tremendous summary of these issues, The Responsible Software Engineer , editors Colin Myers, Tracy Hall, and Dave Pitt (1997) assembled a number of papers that address many aspects of ethics, project management, and project work in business. Simply put, professionalism is not merely the adoption of best practice, but also the adoption of a meaningful code of ethics. |
EAN: 2147483647
Pages: 136