Abstract: Talking about the difference between doing the right thing and in the end what is the right thing to do. Ethics, architects and what to do…
I’ve written quite a few posts on ethics over the past few months. The question I got earlier this month however really threw me for a loop. I hadn’t thought about it, so I thought about it, talked with people I respect and gathered some thoughts and ideas.
The question is as follows: ”What is in the end the difference between doing the right thing and the right thing to do?” It is a decision that architects often have to make. One that takes consideration and sometimes more time than you get to make the decision.
It isn’t in the end a subtle difference. It is more of a brick and a bat kind of difference. The right thing to do in the end is something that transcends what you are doing now and encompasses a larger bigger picture view of what could happen. Determining the right thing to do is often about looking ahead to what will happen based on all the possible scenarios.
My favorite example is deploying a patch you know will blue screen 1/100 PC’s (a constant blue screen loop). The right thing to do would appear to be not deploy the patch. But if you leave the security vulnerability the patch fixes around you will cost the company a lot more than 100 helpdesk calls. The right to do is deploy the patch.
Reality is that many people choose to do the right thing and avoid the issue of a 1/100 blue screens by not deploying the patch. The difference in the end between the two ultimately the impact of the decision.
Accounting for vulnerability in making decisions is important. Considering the impact of vulnerabilities is critical. In my email exchange with the person that asked the question above I gave them the example above. She came back and asked me what if the number was 1/1000 or 1/10,000 PC’s would be forced into a constant blue screen loop. Would that change the answer? Which in the end was a great to ask is this a black and white issue or are there shades of gray.
Accounting for impact is also critical in making decisions. So as the question goes what is the threshold of failure the organization is willing to accept in doing the right thing? Are there shades of gray? Certainly given that we are discussing a system failure based on a vulnerability effectively we have to make sure that the system blue-screening isn’t mission critical. Taking down the accounting system servers with this patch the day before first quarter results are due would be catastrophic and would push us towards saying don’t deploy the patch.
But we won’t know if the patch takes out the servers the accounting system is on. We won’t even know that the patch causes blue screens. It becomes in the end an ethical decision. One that has to be both made and owned. If you choose the right path you deserve any credit due. If you choose the wrong path then it is the ethical architect that stands up and says in the end it was my decision.
I guess to finish out the original question the gray area is the architect making the decision not in the end the decision to be made.
The question is as follows: ”What is in the end the difference between doing the right thing and the right thing to do?” It is a decision that architects often have to make. One that takes consideration and sometimes more time than you get to make the decision.
It isn’t in the end a subtle difference. It is more of a brick and a bat kind of difference. The right thing to do in the end is something that transcends what you are doing now and encompasses a larger bigger picture view of what could happen. Determining the right thing to do is often about looking ahead to what will happen based on all the possible scenarios.
My favorite example is deploying a patch you know will blue screen 1/100 PC’s (a constant blue screen loop). The right thing to do would appear to be not deploy the patch. But if you leave the security vulnerability the patch fixes around you will cost the company a lot more than 100 helpdesk calls. The right to do is deploy the patch.
Reality is that many people choose to do the right thing and avoid the issue of a 1/100 blue screens by not deploying the patch. The difference in the end between the two ultimately the impact of the decision.
Accounting for vulnerability in making decisions is important. Considering the impact of vulnerabilities is critical. In my email exchange with the person that asked the question above I gave them the example above. She came back and asked me what if the number was 1/1000 or 1/10,000 PC’s would be forced into a constant blue screen loop. Would that change the answer? Which in the end was a great to ask is this a black and white issue or are there shades of gray.
Accounting for impact is also critical in making decisions. So as the question goes what is the threshold of failure the organization is willing to accept in doing the right thing? Are there shades of gray? Certainly given that we are discussing a system failure based on a vulnerability effectively we have to make sure that the system blue-screening isn’t mission critical. Taking down the accounting system servers with this patch the day before first quarter results are due would be catastrophic and would push us towards saying don’t deploy the patch.
But we won’t know if the patch takes out the servers the accounting system is on. We won’t even know that the patch causes blue screens. It becomes in the end an ethical decision. One that has to be both made and owned. If you choose the right path you deserve any credit due. If you choose the wrong path then it is the ethical architect that stands up and says in the end it was my decision.
I guess to finish out the original question the gray area is the architect making the decision not in the end the decision to be made.
