Musing about ethics and software develpment

-
There's something that I haven't seen in the education plan of IT degrees ever - professional ethics, and I think it is a huge miss. Ethics is being taught for lawyers, MD, teachers and lots of other degrees. Ethics tells us that there's something beyond our job responsibilities. Ethics reminds us that the one who is footing the bill may not be the final decision maker of everything. That if something is legal, it yet does not mean it is a right thing to do.

Let me share a story about one of my previous project. I was working for an IT services company and we were helping our client to deliver a new version of the software. A peculiar thing was that if there were a bug in the Product, then something horrible could happen (in the worst case - somebody could die). And I was the quality guy on a project.

Our sponsor (the one, who was footing the bill, and ultimate decision maker) had his deadlines. He already made a demo for marketing people and wanted to ship the software. Users we craving to get the new version. But there was a problem.

The problem though was that software quality was a CRAP. Software code was a CRAP. The underlying algorithm was alright but implemented CRAPpily. It was years too late to start building quality into the Product. And this guy wanted us to ship. He told he was taking the responsibility. He didn't see problems with quality. It was not his concern.

We had "no warranty" in the readme, so legally we were fine. My company management was OK to ship (client approves). The client was OK to ship. Seems like we did our job and there was nothing we could do more, let's move on?

But there was something bugging me. It was utterly wrong. One just can't ship Product not having a level of certainty about Product's quality if associated risk is that high. I just could not stand it. I was NOT OK to ship. I consider this to be not ethical to be OK to ship under such circumstances.

Yes, we're here to help to solve one's business problems, to generate more revenue and to service our companies. But there should be a line somewhere one does not cross. There's something that companies should not ask us to do, and we should not agree to do.

I also didn't have ethics classes in university, so I don't think I can teach that, but there's one heuristics that I have. Whenever we're trying to meet our company goals and advancing its business we should never do things that have a high probability of damaging interests of our Product users. That is unethical. And if we have self-respect - even the most generous bonus should not outweigh this.

Comments

Post a Comment

Popular posts from this blog

Test automation framework architecture. Part 2.1 - Layered architecture example

-
Image
Let's consider an example of what Layered (Tiered) architecture may look like for a test automation framework. As a system under test, we're going to use this simple and neat "Todo list" application. First, let's do a brief analysis of the application. From my brief exploration I came up with the following checklist: Area/Group Things to check Comments Todos CRUD 1 Create item Basic scenario, UI-level case 1.1 Create an item with the same name The case is not valid. There's no validation for that - nothing to check really. 1.2 Create an item with an empty/not valid/malicious name While it would be a nice thing to test manually, from test automation standpoint I would expect this to be filtered on service or repository level, so either integration or unit test . 2 Mark item complete Basic scenario, UI-level case 2.1 Un-mark item complete Basic scenario, UI-level case 3 Delete item Basic scenario, UI-level case 3.1 Delete item
Read more

Test automation framework architecture. Part 2 - Layered architecture

-
Image
Probably the most popular architecture pattern used for test automation frameworks (TAF) is layered architecture. This pattern is so well known that on job interviews for some companies when they ask you about TAF architecture you are supposed to describe this one. If you don't - they think you know nothing about the architecture altogether. I suggest you first read a brilliant description of the pattern at the O'Reilly web page , cause in this post I am going to describe the pattern in a way it is usually applied to build test automation solution. Usually, there're three distinct layers, which may have different names, but follow the same logic mostly. Sometimes those layers called test layer , business-layer and core layer , but there're no standard names really. Key rules for layered architecture are the dependency direction (each level depending on the level below) and call direction (no level can call/reference code described in the level above). The rough
Read more

Efficient test automation - Secret #1 | Test Club

-
Image
It seems everyone talks about efficient test automation, but not so many people have actually seen it! To cover this I decided to make several videos regarding the secrets of efficient test automation. Today we will talk about the first (and, arguably, the main) secret - realistic expectations. Very often, test automation projects or initiatives are started with the following unrealistic expectations: "Test automation will replace 'manual' testing" "Test automation will provide fast results and benefits" "Test automation efficiency depends solely on test automation engineers" Unfortunately, all those expectations are not realistic! Watch the video to know more!
Read more