Our Solution

ACCOUNTABILITY: AN INDIVIDUAL OR COMPANY’S RESPONSIBILITY FOR ACHIEVING THEIR GOAL OR RESULT.

Currently, there is no organized or enforced system of accountability in software development. It is only up to the offending company’s discretion to pay reparations and apologize to the consumers for bugs in its product. Often the company will be reasonably generous in this regard for the sake of its image, but when the software defects cost people their lives it is no longer enough to leave reparations to the discretion of the company.

Accountability is the main motive behind licensing and mandating development methodologies. Ensuring accountability achieves two main purposes – it holds the offending company liable for any damages that arise from its software, and in doing so it also pressures companies to output higher-quality software. Unfortunately, the primary traditional method of enforcing accountability, licensing, appears to be either ineffective or infeasible in software development.

We believe there are other means of enforcing accountability that avoid the problems faced by the other two strategies we’ve discussed. This means we would prefer to avoid attempting to manage the diverse range of software applications with a single entity or a single set of laws. We do not want to dictate how the companies produce their products or what skillsets its employees must have. In the end, we only care about the quality of the end-product, not how it was created and by who.

The natural solution to this is to simply hold companies liable for damages caused by their products. Such a system would not directly interfere with companies’ production processes, giving companies continued freedom to develop in whatever manner suits their application best. At the same time, it would give companies second thoughts on releasing software which is not top quality. Furthermore, this solution directly addresses the point we care most about: the quality of the end-product.

One method of holding companies liable for software defects is to fine the companies in accordance with the level of damage its software has caused. The punishment could include requiring companies to fully reimburse consumers for damages incurred. This will certainly raise issues regarding whether the defect could have been prevented, and how to evaluate the severity of damage and amount of compensation. Furthermore, what software would be covered under this law is a gray area since not all software is produced by companies. We do not attempt to address these details as they are far beyond the scope of our purpose, but nonetheless it is clear that this mode of ensuring accountability is a step in the right direction.

One ¬†deficiency with this method however, is that the company as a whole gets punished; the pressure to output high quality code is felt at a company-level, not necessarily at the level of the individual coders. However, software defects often arise from the carelessness of the individual engineers. We may therefore, wish to find a way of ensuring accountability on the level of the individuals as well. We might achieve this by indeed, requiring software developers to acquire a license. We would, however, make the “body of knowledge” consist of some small number of fundamental concepts which any programmer should know. The body of knowledge should be sufficiently modest as to not exclude the majority of those software engineers who are working with proficiency today. The acquisition of the license becomes quite feasible, but we require that every software engineer acquire one. If the engineer is found liable for software malpractice, the license may be revoked.

In this way, the software license, while not playing the traditional role of serving as a strong statement of competence, instead becomes a means by which the software engineer may be held liable for carelessness. It is similar to a driver’s license, which does not have a high barrier to entry but nonetheless has value, since one cannot drive without it. To use inspiration from this analogy, we may allow reacquisition of the software license after a required number of hours of “school” and/or community service.

This software license could be used in combination with the strategy previously discussed in order to impose accountability both on a company level and on an individual level. While our recommended policies will certainly raise more questions concerning the details of their implementation, we believe that this is a strong step toward a solution which increases pressure to output high quality code and holds the offender accountable, all while simultaneously allowing companies to continue to operate with the same workforce, freely.