1.01. Accept full responsibility for their own work

Software Engineers should be able to accept the full responsibility for their own work. For an example if you deliver a buggy software product the Software Engineer should be able to take the responsibility of it. In our project we had to work with the Rotaract Club of University of Colombo, Faculty of Science which is a club that largely interacts with community. If the website we are creating for them is faulty it would affect their image as a club. So we had to be sure that we deliver a high quality product as well as that we are responsible for the product that we are delivering.

There were few other issues as well. As most of the board members of the club are personal friends the liability that is on our heads was greater than a normal scenario. Because we knew that if something went wrong they would come to us straight forwardly. So we had to make sure that the product is not faulty because not only we were professionally liable but also we were morally liable to the product that we are delivering.

After delivering the site few issues came that we didn’t find out during the testing phase. For an example an issue came with the gallery module which restricted the number of images to be visible in a page. Which we didn’t find earlier because we didn’t upload a large number of images and test. They told us about the issue and we immediately fixed the issue by increasing the number of photos for a page. Another example was that there was an issue in one of the categories’ pages which made the page out of aligned. We had to fix the code after they informed about it.

So as a Software Engineer we have to take the full responsibility of the product that we are delivering because we made them and most of the times the client is a non-technical person who is unable to fix the issue by their own and rely on the person who created the software to correct it. In our project we had the personal connection as well which made us highly responsible of the deliverable.

2.02. Not knowingly use software that is obtained or retained either illegally or unethically.

In Sri Lanka this is a huge problem for most of the Freelance developers because they don’t have the capital to invest in software licenses. Because of that most of the developers tend to go for open source alternatives or in some cases cracked software. But if you are following the ACM Software Engineering Code of Ethics it clearly says that you should not knowingly use software that is obtained illegally or unethically. The infringement of this code occurs only if the person who is using the software knows that it is illegally taken, which is the case in the use of most cracked software.

As developers of the website of Rotaract Club of University of Colombo, Faculty of Science we also had to face such situations. Because some of the plugins that we needed to integrate were not freely available. So the option we took is going for the freely available alternative tools. But some of the alternatives doesn’t give the full functionality that we needed which were there in the paid tools. So to overcome that issue in some plugins we had to write our own code to do the additional functionality and in some cases by integrating some other free tools we were able to get the work done.

Going to the open source versions led to more flexible integration of tools which made the tools more custom tailored. One other advantage that we saw in the free tools is that as some of the tools are really light weight we were able to improve the performance of the web site. Because as we found out some of the paid tools were relatively slow due to the variant of functionality that comes integrated with them, some of them which we didn’t need. So by selecting a specific tool that only does the job that we need we were able to improve the performance of the site as well.

This is how we addressed the ACM Software Engineering Code of Ethics rule number 2.02 , by going for free alternatives.

3.07. Strive to fully understand the specifications for software on which they work.

This is one of the closures that a software engineer should really consider about. Because unless the developer doesn’t know the specifications for the software properly there is no guarantee of a good out come. Before developing a software, a developer should always have good understanding of the specifications. This scenario can be interpreted in many ways.

For an example if you are a Freelance developer and if you are undertaking a software project from a client, unless you understand the specifications that he needs you can’t really agree upon on the project. If the developer agrees upon on the project without understanding the specifications, at some point of the development life-cycle of the project the developer realizes that he or she has undertaken a task that is unachievable. When the developer realizes this it may be too late.

In another scenario a developer might be working in a software company. He might be given a software to be developed that has undertaken by the company. If he starts to develop the software straight away without getting a fully understanding of the specifications the ultimate product may have functionality that is not expected.

In the project that we did for the Rotaract Club of Faculty of Science, University of Colombo, we took a reasonable time to get familiar with the specifications that they wanted and took out the ones that seemed unviable during the time period and told them about the issues with the specifications. One such incident was the payment gateway that needed for the site. After doing some research we found out that a payment gateway costs way more than what they can spend on it. We mentioned that to them and we had to remove it from the specifications of the web site.

Other than that we didn’t find any specification that was unfeasible. We read the specifications thoroughly to get the complete understanding of it so we won’t get stuck in the middle of the development process. The development becomes pretty easy when you get the understanding of the specifications. Earlier in some scenarios I have faced in to some set backs due to not reading the specifications properly. This closure helps both the developer and the client to get a better product and it also helps the life of the developer easier.

5.06. Attract potential software engineers only by full and accurate description of the conditions of employment.

This closure is for the management of a software development company or a project. This closure says when you are attracting suitable software engineers to your project you should provide a full and accurate description of the conditions of employment. This is a really important closure that management should consider. Not only managers, developers also has the right to know the full description of their employment. Otherwise it may lead to some complications afterwords.

For an example lets take a scenario where a developer is hired by a company that makes games for foreign companies. An aspiring developer joins the company and he was told that the company is making novel good quality product. The developer who also has a passion in gaming and also wants develop something new joins the company. But after sometime he realizes though the company makes good games it is very rarely done. Most of the time they only make flash based games for client needs which are not that advanced. The developer was not expecting an environment like this.

Likewise in our project also this closure became very important to us. The project we did, web portal for the Rotaract Club of Faculty of Science, was basically project that I received because most of the people in the club were my friends. They also told me that they won’t be able to pay for the project which I was okay with because they can give recommendations to other people as they are working with a large community that has many potential clients and so on.

After listening to this I asked from my team members that we can do this project and also told them that there won’t be any straight forward financial benefits from the project. I also told their requirements and the deadline that they suggested and asked whether we should take it or not. Finally we agreed to take the project because we came in to consent that the recommendations that we get afterwards would be beneficial for us.

If I have not being truthful with my team members and told only about the project and not about the compensations there is a possibility of they expecting a one. Because I told the whole situation to them only we were able to come for a consent about the project. This closure is really important when it comes to hiring or involving other software engineers in a company or in a project because it ensures that there won’t be any complications down line of a development process due to the information not provided.

6.04. Support, as members of a profession, other software engineers striving to follow this Code.

This closure is important when working with a team. Because this closure promotes team members to work with each other in a more ethical way. A software engineer should support other software engineers who are trying to follow the software engineering code of ethics. As software engineers we should always try to follow the conducts mentioned in this ACM code of conduct. Because it promotes a healthy development environment that would ensure to produce better relationships between clients, employers and also employees. It also helps to develop a better quality software. 

When a software engineer who is following this code of conduct sees another fellow developer who wants to follow these rules he should always help. Because by promoting this conduct we can guarantee to obtain the above mentioned goals. If the other fellow software engineers are not following this code or doesn’t know about them you can encourage them to follow it and introduce them to it. If they have any hard time following a closure mentioned in the conduct you as a person who follows the conduct should tell the proper way of following it.

By doing so in a team there is a very less probability of any of the team members doing something that is deemed unethical by this code. If everyone in the team acts like that there won’t be any ethical issues that would arise during the development of the product. Also as it encourages of using better standards of coding and also improving the skills there is also the advantage of being able to deliver a superior product.

The closure is there for the betterment of all the software developers. Because by doing unethical work the developers are the ones who is going to take the black mark. Sometimes without even knowing an unethical conduct may happen due to not properly knowing what is in this conduct. If a developer is fully aware of this code of conduct that person is able to reason an act according to this conduct before he do it. By promoting this code of conduct like this there is the possibility of majority of developers following this code which lead to a better development community as a whole.

8.02. Improve their ability to create safe, reliable, and useful quality software at reasonable cost and within a reasonable time.

The 8th Principle of the ACM Software Engineering code of ethics is promotes the self learning ability of the Software Engineer. It says that 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.

This 8th principle is one that heavily emphasizes the improvements that Software Engineers should make both professionally and ethically. It addresses the long term behavior of a Software Engineer. Software Engineers should always be up to date because the IT industry is one of the most dynamic fields.

A Software Engineer should always try to update his knowledge and to improve his/her skills. It is an essential quality that a software engineer should have. Otherwise it is really hard for a software engineer to survive in the IT field. According to the the sub closure 8.02 of ACM Software Engineers Code of Ethics it says that the self should always improve their ability to create safe,reliable, and useful quality software at reasonable cost and within a reasonable time.

This point is a one that we can emphasize a lot in projects as it helps the software engineers to create more reliable software to the customer as well as give customer satisfaction as well. In our project also we ensured that we always create a reliable web site using the past experiences we had. This is what this closure is all about. Learning from your previous experiences. While you are developing software you get the experience of what is best and what should be avoided. This knowledge can later be applied in to the development of other developments which we used in this scenario.

For an example in a web site we created earlier we used a module that was faulty. But we fixed the module and used it in the site and it worked fine. But during this development we were able to find a more advanced and a reliable module that was also freely available. The lessons learnt from earlier helped us to improve the reliability and safe of the current project. This learning curve of software engineers would never end. As technology evolves he/she should always try to improve themselves with the latest technology and trends. But they should adapt in to these trends only if they make the work that you are doing more reliable and safe.