Sunday, January 26, 2014

Client confidence

One thing that is obviously very important for any company to succeed is the customers' and stakeholders' confidence in the company they will be interacting with. Things that disrupt these relationships can have dramatic effects on the future success or failure of the company in question and software development is no different.


I personally, find security very interesting. When looked at security from a consumer point of view, if a product is insecure or perceived to be, obviously customer confidence becomes an issue. If it becomes such an issue as to be made public and/or widely discussed the confidence of investors and share holders in the company can become a real issue.


A division of EMC that recently came under fire was RSA. Edward Snowden disclosed information implicating RSA in creating software that used insure encryption functions by default on some of it's products. The NSA purportedly paid RSA 10 million dollars to build these insecurities into their products.


When this was made public it had several harmful implications for EMC. The first is obviously that consumer confidence in RSA was shaken. This was observed when several (8) security professionals boycotted the 2013 RSA Conference[Source].


The fact that this news has been made so public, at least in the security community, means EMC/RSA
now face a real problem with their stakeholders' confidence in the financial integrity of their investment since customer confidence has been effected by Snowden's disclosure.


So far we have looked at this issue from the stand point of the client side; the consumers of the software, and the people investing money in the company. One issue that is just as valid but maybe not considered as often is the point of view of the company and the developers that implemented the software. What kinds of things does one have to consider when actually implementing a system with respect to the consumer. What kinds of responsibilities do we  as developers owe a client when making a software system. What kinds of ethics does the developer need to consider when working on non-trivial systems in the real world? Is it more important to have listen to the boss and just add the "feature" (vulnerability) or does one go against this in the better interest of the end user?


This is an interesting topic that is common to many disciplines, not just software engineering but we as developers stand in a unique position as we are ultimately the ones responsible for these decisions. In my next post, I plan to delve a bit more into this topic to really discuss the kinds of issues that a developer is responsible. I might touch on the topics like the difference between the open source versus proprietary paradigm.

No comments:

Post a Comment