Got Tethics?
NOTE: This post contains spoilers for season six of the HBO television series Silicon Valley.
In order to achieve greatness, we must first achieve goodness.
–Gavin Belson, Silicon Valley
In the opening episode of Silicon Valley’s sixth season, Richard Hendricks testifies in front of Congress regarding his company’s decentralized internet, PiperNet. He promises that his company will not collect user data, unlike the other fictionalized versions of big tech companies present in the episode, only to discover later that user data collection is in fact happening on his network. Fast forward to episode five of the season. Gavin Belson, Richard’s rival, has created a code of technical ethics, or “tethics”, for the technical industry to follow in the wake of the congressional hearings. Richard is frustrated at what he perceives to be a lack of genuineness on Gavin’s part, with much disagreement from others. And soon Richard discovers that the statements in the Tethics code of conduct are plagiarized from other companies’ mission and vision statements.
In a tweet from Alistair Kyte, we can see what Gavin Belson’s Tethics Code of Conduct looks like:
(Image source here)
As I’ve watched through these episodes and read through this fictional code of conduct, it has me wondering: what would an actual code of ethics for software development look like? Let’s get tethical!
In 1997, the ACM/IEEE-CS joint task force on Software Engineering Ethics and Professional Practices (SEEPP) developed a software engineering code of ethics. The short version of their code of ethics is included below, but the full version can be viewed here and here.
Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:
Public: Software engineers shall act consistently with the public interest.
Client and Employer: Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.
Product: Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.
Judgment: Software engineers shall maintain integrity and independence in their professional judgment.
Management: Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.
Profession: Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.
Colleagues: Software engineers shall be fair to and supportive of their colleagues.
Self: Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.
It’s a good list, and I would encourage you to look at the full version. I especially like the callout to management in this listing. As I have previously covered, there are a variety of questionable behaviors that management can bring to an organization that can impact the software development process. Good to keep these in check.
Another great set of ethical principles comes from Bob Martin’s 2015 talk, Expecting Professionalism. I have included a listing and summary of his main points (with timestamps) below:
We Will Not Ship $#!+: We will not knowingly ship code that is defective or substandard.
We Will Always be Ready: At the end of every development cycle, the code will be deployable.
Stable Productivity: You will produce features just as fast a year from now as you produce them today.
Inexpensive Adaptability: The business should not find it expensive to adapt the system to new requirements. It should be easy to change the code.
Continuous Improvement: The software gets better with time, the code gets cleaner with time, the designs improve with time. Every system should be getting better and better, not worse and worse.
Fearless Competence: If you had a comprehensive automated test suite that you trust, you could clean the code. If you could clean the code, then the code would always get better. If the code always got better, you could make it easy to change. If you could make it easy to change, you could go fast. That test suite is the key to everything.
Extreme Quality: Expect that the software is going to work release after release.
We Will Not Dump on QA: QA will find nothing.
The Vast Majority of the Testing Will be Automated: Manual testing always ends with you losing the tests. More commonly, you lose them by QA deciding not to run them. Because they don’t have time. QA will decide which tests are the most important to run and which are the least important.
Nothing Fragile: Nothing in the system will be fragile.
We Cover for Each Other: If we’re working in a team, if Bob gets sick, someone else should be able to step in and take over for what Bob was doing. And who’s responsibility is it to make sure that someone can step in and make sure that they can take over for what Bob was doing? It is Bob’s responsibility to make sure that someone can cover for him.
Honest Estimates: I want 3 numbers: the best case, the expected case, and the worst case.
You to say “No”: You were hired for your knowledge. And your knowledge gives you the privilege and the responsibility to say “no” when “no” is the answer.
Continuous Agressive Learning: You, as software developers, should be learning all the time. Learning a new language every year or two. You should learn new platforms, new operating systems, new frameworks. You should be fiddling around, playing with stuff. All the time. Because our industry is one that is constantly changing.
Mentoring: Half the programmers in the world have less than 5 years experience. Which puts our industry in a state of perpetual inexperience. How do we address the fact that all of the experience shrinks to insignificance in the face of the massive number of young graduates pouring out of the universities and getting hired. University does not prepare you for what’s really going on in industry. It would be wise for companies and programmers to make sure that new kids coming out of school are not allowed to touch any of the core code for a year or so. Take them on as apprentices. Mentor. Teach. Make sure they’re not turned loose on their own.
As I look through this list, it is clear that in order to meet these statements, you must change the way you tackle software projects. What planning you do up front, the technical approaches you use throughout the project, the underlying design of the system, and the roles that various personnel play at every step. It’s not enough to just deliver the requirements here and now; it’s necessary to consider impacts over time. It’s worth some additional consideration.
I’m reminded of a previous customer of mine, whose stated goal was not to be merely compliant but to be above reproach in everything they did. What do you think are essential items to cover in a software development code of ethics?