A Code of Ethics Does Little to Correct the Issues with Today’s Software

3 min read

Malicious software stories fill many publications. Bleeping Computer is practically an active record of malware and security holes. Bulletins such as The Daily WTF are a constant reminder of the general bugginess of applications.  The current set of programs leaves much to be desired. Today’s software landscape needs a fix.  One repair proposed by some is a code of ethics.  However, this improvement is unlikely to improve the panorama of today’s programs. A code of ethics is an improbable path to better software or the avoidance of poor outcomes.

Ethics do not lead to the adoption of sound software engineering practices.  An agreed-upon ethos can provide goals, but it does not present a way to achieve those ends.  For example, a common objective is a commitment to quality software.  However, the intention to reach a target does not equip a developer with the tools to do so.  Most programmers intend to produce good products, yet they fall short of that ambition.  When goals for excellence are met, engineers are likely to have adopted sound development practices.  The adoption of proper engineering habits does not stem from the acceptance of a code of ethics.  An ethos can provide ends, but it cannot provide knowledge.  The possession of expertise is what leads to compliance with solid software development approaches, not a code of ethics.

Conventions for conduct will not lead to better products, while the adoption of proper engineering methods will.  To produce better software, a team must embrace sound programming practices.  A unit that implements code reviews will produce better systems than a group than merely adheres to a code of ethics.  An ethos provides ends, but it does not provide tools.  A rule requiring the pursuit of quality does not provide the means of achieving of that goal.  Those mechanisms are provided by solid development habits.  Code reviews reduce bugs.  Fewer defects are associated with improved quality.  That purity target is met through sound engineering practices, not a code of ethics.

Behavioral conventions do not reduce the likelihood of bad outcomes such as security holes, while solid programming habits do.  A mandate for security does not provide the tools that actually decrease the likelihood of exploits.  For example, threat modeling decreases protection flaws. However, the tool must be utilized by a team, before any benefits are realized.  To accrue any rewards, a group must know that a technique exists, before it can use that approach.  Knowledge of a tool such as threat modeling does not flow directly from any behavioral rule.  Conventions provide ends, not means.  Methods are provided by sound development practices.  Good engineering habits reduce the likelihood of bad outcomes, not behavioral mandates.

A code of ethics cannot remove a market for certain bad outputs such as malicious software. Ransomware has a market. Crypto-miners have one too.  A product has an economy because that product has both producers and consumers.  Ransomware and crypto-miners have people who value them.  Individuals are willing to exchange something to acquire that software.  Ransomware is being sold on the Dark Web right now.  Those products do not appear ex nihilo. They have developers who produce them.  Those programmers could be shamed into abstention by a code of ethics, but at least one engineer will find a customer who offers a price high enough to assuage the developer’s shame.  Opprobrium only raises the cost of doing business.  A programmer asked to build ransomware demands more in return to build that software.  A customer for a crypto-miner requires a larger payout to justify the price demanded by the producer.  The developer will not bbuildransomware or a crypto-miner, unless he knows a buyer is willing to pay his price.  As expenditures rise, the number of customers fall, but that number is unlikely to fall to zero.  At least one consumer exists for every market, even ones with a strong sense of embarrassment attached to them such as the murder-for-hire industry.  If killing for cash cannot be dissuaded by humiliation, then guilt is unlikely to convince a programmer to abstain from building malicious software.  If shame cannot stop engineers from building ransomware or crypto-miners, then a code of ethics cannot get rid of the market for cdertain bad outcomes such as malicious products.

Many undesirable results and many disputes are already handled through the existing legal code, making behavioral conventions unnecessary from a jurisprudential standpoint.  Ransomware and crypto-miners commit extortion and theft respectively, which are already criminalized acts.  Efforts that result in harm also have associated criminal offenses. Even disagreements over legal liability, contracts, or responsibilities are handled through the law already. Jurisprudence in the Anglosphere has been refined and honed over hundreds of years. The current legal system would see little benefit from ratifying into law a code of ethics specific to software developers.

An ethos is unlikely ito mprove the landscape of computer programs or to avoid poor results. Behavioral conventions do not lead to the adoption of solid engineering practices. Sound development methods lead to better products, while rules for conduct do not. Ethics do not make bad outcomes less likely, while sound engineering techniques do.  Sensible, proven, and sound practices are what will fix the ills of the software world, not a code of ethics.

Collin Rusk Since the mid-2000’s, Collin Rusk has worked on a variety of projects, using his interest and expertise in software engineering to develop and/or architect enterprise systems. Business products have unique challenges. Enterprise systems are often complex, and they typically have to be supported for a period of at least a decade. Long support-durations and complexity make shortfalls in software engineering particularly harmful. Those deficiencies can cost an organization hundreds of truckloads of cash. Inadequacies on multiple products allow those amounts to accumulate to destructive levels, an event that Collin has witnessed multiple times. Those events, and his own mistakes, have spurred his interest in software engineering (a distinct concept from programming). Collin has used that interest, and the knowledge gained from it, to move the enterprise systems that he builds in a less destructive direction. Collin has been architecting enterprise software since 2010. He has a B.S. in Management Information Systems from Le Moyne College and an M.S. in Computer Science from Lawrence Technological University. Collin is interested in a variety of subjects. Using those areas, he attempts to augment his software engineering knowledge.

Leave a Reply

Your email address will not be published. Required fields are marked *