The History Of A Software Engineer

Published Date: 02 Nov 2017

It is important to understand from the scenario, that the professionalism of the technical staff was at risk. The technical staff should have reported to the client organisation. This is due to the code of ethic which each engineer must uphold. The code created by "ACM/IEEE-CS" by the executive chair Donald Gotterbarn (ACM 1999) state in article:

6.08: Take responsibility for detecting, correcting, and reporting errors in software and associated documents on which they work.

2.06 Identify, document and 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 laws, or otherwise to be problematic

2.03. Use the property of a client or employer only in ways properly authorized, and with the clients or employer's knowledge and consent.

Upon considering the code stated it is possible to draw a conclusion that the technical staff should inform the client organisation. Upon withholding information and not "reporting" it to the client organisation without there "knowledge of consent" is breaking the code of ethics. In addition, the scenario state that the given project won’t be "completed as promise".

Breach of Contract:

One of the most important concerns is the breach of contract. The breach of contract is a term used to define a breakage of a legal binding agreement between two parties. It is up to the parties to uphold there agreement and term which they have stated within agreement within the contract. By breaking the term of a contract the other party can then take legal action. ().

Within the scenario, the technical staff in question are breaching there contract and the professional code. Consider the code of ethic, clause 6.08 reports that an engineer must also document any detection or error within their software. However a survey conducted by Rogerson have shown that 20% of IT professional "provided with a brief specification, to go ahead and develop the system knowing that in the future re-work under another contract will be essential" (Rogerson 2001). In addition within Rogerson report he also goes on stating that "keep stakeholders informed is sufficient" (Rogerson 2001).

In addition clause 2.06 which state to identify and report if a project is likely to "Fail" or "violate intellectual property laws, or otherwise to be problematic". If the technical staff don’t report to their client is it hence breaking the ethical code and breaching there contract. However it is important to take in account a certain biased toward the result as this is based upon survey research and also out-dated.

Disapproval of the Professional Code

One of the main areas which the code itself has been criticised is that "violating the professional code" does not actually damage the employment of the individual (HALL, 2009). Unlike other professional field such as medicine which violation of the "Hippocratic Oath" can lead to the loss of the individual employment, the code of ethic for software engineer contain no law which can cost the software engineer there employment (QURESHI, 2001).

In addition a survey by Ben Fairweather (2001) found that the codes have been built upon four criteria which are "privacy, accuracy, property and accessibility". In addition Fairweather also claimed that the code contain "loopholes" which can also allow employees to act in unethical ways as well (HALL, 2009). I will now give similar scenarios which displayed the failure of IT projects.

Similar Scenarios:

The failure of an IT project can be costly as well having an impact on other major area such as medical and business criteria. A survey conducted by Lyytinen and Hirschheim display four main criteria which is associated with project failure (K.T, 2002):

Correspondences Failure: Is when the design of the system in question is not met. The actual objective of the system itself and it requirement are not met the project will be consider a failure.

Process Failure: Is when the product itself goes over the budget and time given to create it.

Interaction Failure: Is based upon the end of user requirement. The amount of user which uses the product after production can influence if the product was a success or a failure.

Expectation Failure: This is based upon the view of the stakeholder who has invested within the product. Of the product itself does not meet the stakeholder standard the project itself is consider a failure.

A similar example of a software failure which results in $25 million dollars fined by Securities and Exchange Commission is the AXA Rosenburg Group software glitch. AXA group is an industry which invested in trading approaches by creating computers algorithm. A software glitch which occur with the AXA system was not reported to the Employers which cost there investor $217 million dollars (GREENE, 2011). The company was henceforth fined $25 million dollar Securities and Exchange Commission and had their software investigated by exchange commissions as well.

In addition another software failure which causes a huge impact was the London Ambulance Service (known as LASCAD). This project itself was based upon introducing a new way which computerises technology can replace the manual handwritten system which was still being used. However first failed attempt at the service loss over £7.5 million. A second attempt was then consider at 1992 however "barely 9 days" the project was deem a failure which cases a loss of lives and financial resources (ALKAZM et al).

Safety Critical Software:

Safety Critical software itself is software associated with "life-threatening impacts" (BOWYER, 2001). These types of software are mainly defined as software which can cause great damage such as missiles systems and medical treatment systems (HALL, 2009). Consider the case study Strategic Defence Initiative (SDI), which is based upon missile defence system which provides a defence against oncoming missiles. The project consultant, David Parnas left the project for the reason that SDI could "not be trusted" as proper testing of the software have not been done (HERMAN, 2004). Parnas have then been greatly criticised by being "Disloyal" to the SDI. The project itself was then shut down. Did Parnas had the right had the right to blow the whistle to the project.

Whistle Blowing:

The term Whistle blowing can be define as the act of "call attention to negligence, abuse, or danger that threaten the public interested" (BOK, 1997). Of course it not possible within the scenario to know what the purpose of the project is however it is important to consider whistle blowing nevertheless. For an individual to blow the whistle could cost the project and loyalty of his fellow employees however it could save millions of lives.

Consider the case study of the AXA Rosenberg group, if the individual did blow the whistle he could have save investor millions of dollars. However, if he did he would have been disloyal to his supervisor and his employees. Also consider the LASCAD scenario which cost millions of lives. Most employees should have the right to blow the whistle however it is due to authority which they don’t. This is due to the fact that most employees might find a bug within software, however unsure if it truly consider as a bug (QURESHI, 2001). This could have been the case of the AXA Rosenberg software glitch. Since the software engineer profession are based upon stressful environment this could cause most individual to second question them self. This hence could lead to error in their work and can stop them from blowing the whistle.

Richard De George has stated specific criteria which need to be met before an "engineer" can blow the whistle. In addition he also mention that the "worker can go to public if the following condition are met" (HALL, 2009). (See Appendix A). With the criteria stated by George this give "engineer" right in order to blow the whistle at certain criteria giving them some form of authority.

Recommendations:

In order to improve the quality of control to ensure that the project itself does not failed, I recommend two factors which can help project managements. The first factor is client’s relationships with the team. Improving the client relationship and communication with the team can hence improve the quality of the product and time management. As you can see from the scenario, there was a weak relationship between the "Technical staff" and the client, which could have resulted to the failure of the project. Second factor is stronger set of requirement and objectives. A stronger set of requirement can hence improve time management and the use of the budget.

Conclusion:

Even though with the scenario given does not states what the purpose of the project, considering the amount of money involved should cause concern about the implementation of the software. The morality of the issue here displayed that the technical staff should inform the client organization even thought it could be called a "Process Failure" (K.T, 2002). Without informing the client could cause a huge impact not only on the client but also on member of the public. It is up to individual to learn from their mistake, but also to learn from other.

Bibliography:

ACM (Association for Computing Machinery) (1999) / Executive Chair: Donald Gotterbarn / Software Engineering Code of Ethics and Professional Practice / URL: http://www.acm.org/about/se-code / Last Updated: Not Mention / Date of Access: Jan 17 2012, Time of Access: 03:56

ALKAZM. Abdulhameed et al (Date not Mention) / London Ambulance Service Software Failure / URL: https://www.cs.kent.ac.uk/teaching/09/modules/CO/8/86/rdl/CaseStudies/Reports/reportLondonAmbulanceS.pdf / Publish Date: Not Mention / Date of Access: Jan 29 2012, Time of Access: 01:12

BAYLES. D. Michael (1982): Professional Ethics (2nd Edition) / ISBN: 0534095461 / Publish: 1982 / Wadsworth Inc.

BOK, Sisela (1998): Secrets: On the Ethics of Concealment and Revelation / ISBN: 0679724737 / Publish: Mar 1998 / UK: Vintage Books

BOWYER. W. Kevin (2002): "Star Wars" Revisited - ETHICS AND SAFETY-CRITICAL SOFTWARE / ISSN: 0278-0079 / Volume No: 2 / Publish + Copyrights: IEEE Technology and Society Magazine/ Date: Nov 2002

Ben Fairweather 2001: Ethic Technology-Ethical Issues in an Age of Information and Communication Technology / ISBN: 0471452505 / Publish: 2004 / USA: John Wilkes Publishers

ROGERSON. Simon (2001): Is IT Ethical? 2000 ETHICOMP Survey of Professional Practice / ISSN: (Not Stated) / Volume No: 11 Issue No: 6 Publish + Copyright: ETHIcol in the IMIS / Date: 2001

George

GATTIKER. U. E. (1999): Morality and Computers: Attitudes and Differences in Moral Judgments / ISSN: 1047-7047 / Volume No: 10 / Issue No: 3 / Publish + Copyrights: Information Systems Research / Date: Sept 1999

GREENE. Tim (2011) / Network World: Financial firm fined $25M for hiding software glitch that cost investors $217M / URL: http://www.networkworld.com/news/2011/020411-axa-rosenburg-group-glitch.html / /Last Updated: Feb 4 2011 / Date of Access: Jan 29 2012, Time of Access: 12:21

HALL.D (2009): The Ethical Software Engineer / ISSN: 0740-7459 / Volume No: 26 / Issue No: 4 / Publish + Copyrights: IEEE Computer Society / Date: Aug 2009

HERMAN. T. Tavani (2004): Ethic Technology-Ethical Issues in an Age of Information and Communication Technology / ISBN: 0471452505 / Publish: 2004 / USA: John Wilkes Publishers

K.T. Yeo (2002): Critical failure factors in information system projects / ISSN: 0263-7863 / Volume No: 02 / Issue No: 20 / Publish + Copyrights: Elsevier Science Ltd and IPMA / Date: 2002

QURESHI. Shoaib (2001): How Practical is a Code of Ethics for Software Engineers Interested in Quality? / ISSN 0963-9314 / Volume No: 9 / Issue No: 3 / Publish + Copyrights: Kluwer Academic Publisher / Date: Nov 2001

Bibliography:

BASSINGTHWAIGTE. C. S. Mark et al (2006): The Top Ten Causes of Malpractice – and How You Can Avoid Them / URL: apps.americanbar.org/lpm/lpt/articles/tch12062.pdf / Publish: ABA TECHSHOW / Date: 2006