What is the role of programmers in software development? The question is never far away in free and open source software (FOSS). Last month, however, the issues surrounding the question were emphasized by Robert C. Martin’s attempt to write a programmer’s oath that states best practices and the resulting discussion.

Martin emphasizes the pride that many developers take in their work, but the discussion produced by his effort is equally worth reading for topics that are not mentioned and possibly should be — including the relationship between programmers and users, the limits of meritocracy, and whether any effort should be made to have developers on a project actually take the oath. At a time when similar codes of conduct are being adapted everywhere, these are all questions worth considering.

Martin describes the oath as

… hastily thrown together and shared on Twitter.

Influenced, perhaps, by the seriousness of the word “oath,” he summarizes the role of the programmer in formal, pseudo-legalese:

I Promise that, to the best of my ability and judgment:

1. I will not produce harmful code.
2. The code that I produce will always be my best work. I will not knowingly release code that is defective either in behavior or structure.
3. I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.
4. I will make frequent, small, releases so that I do not impede the progress of others.
5. I will fearlessly and relentlessly improve the code at every opportunity. I will never make the code worse.
6. I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity.
7. I will continuously ensure that others can cover for me, and that I can cover for them.
8. I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.
9. I will never stop learning and improving my craft.

This blog entry received several responses. For instance, Ron Jeffries suggested that the oath should include language about cost-effective and meaningful testing the existence of meritocracy. In effect, Martin’s oath, prompted a sometimes lively discussion between him and Martin. Similarly, Mike Loukides suggested that a clause was needed about programmer’s relationship with customers, such as, “I will make technology decisions based on the customer’s needs, not my own.” However, these examples are only the start of the potential conversations.

Where the interest lies

Loukides’ comments highlight a major assumption in Martin’s original oath: it treats programmers as largely autonomous, answerable largely to their own professionalism and personal integrity. The only obligation that Martin acknowledges even to other programmers is support their autonomy, largely so they will support his. Programmers’ obligations to each other are to ensure that productivity is “as high as possible,” to cover for each other when needed, and to make honest estimates and avoid promises that cannot be fulfilled.

So far as these obligations go, they are admirable in their integrity. The trouble is, though, that they don’t go nearly far enough. The modern programmer, whether they are working in free software or not, is rarely as autonomous as the oath apparently assumes. As Loukides points out, they also need to think about the need of customers — whether “customer” is defined as a literal customer, or the end-user of free software.

This is a discussion that has haunted FOSS for decades. You might say that the original oath has an open source perspective, in that freedom for others is wrapped up in freeing programmers to act on their own integrity. By contrast, the consideration of the customer draws more on free software perspective, in which the emphasis is on a philosophical freedom for everyone.

More importantly, ignoring the relationship to customers can be disastrous. For example, in 2007-2012, the FOSS community witnessed three user revolts against innovations in desktop environments: against KDE, in which programmers failed to make clear that the first releases were intended for developers, and against Unity and GNOME, in which programmers became convinced that they alone knew the best ways for end-users to work. In all three cases, the subsequent success of the desktops depended on how well the programmers learned to listen to end-users. Meanwhile, Linux Mint became a major desktop environment because it made a point of canvassing of users’ opinions.

The lesson? Simply that programmers do not work in isolation. For programmers to strive for integrity and pride in their work is worthwhile, but it not nearly enough to ensure the highest standards.

The Meritocracy Debate

Another problem with the oath is the assumption that all that is needed for excellence is for programmers to live up to their own highest standards.

The idea is appealing, especially for North Americans, who are raised with the idea that meritocracy is an essential part of democracy, and an essential part of their culture. Unfortunately, for over a decade, we have known that the myth of meritocracy can conceal all that it is supposed to replace, including cronyism and favoritism.

For example, the fact that women rarely represent over 15% of people in FOSS projects — and often far less — is evidence of systemic sexism. Too often, women are made to feel like unwelcome outsiders, their competence questioned, and their efforts belittled by ridicule and personal abuse. Yet firm in their conviction that FOSS is a meritocracy, many developers still insist that the fault is in women and their life choices, rather than the community culture.

For this reason, an effective programmer’s oath requires another clause or two about how programmers interact with one another. It is not just a matter of promising to be excellent to each other — whatever that means — or even to be polite or constructive, because, like evoking meritocracy, such promises can be used as a means of discrediting legitimate criticism.

Rather, a commitment is needed to judging code rather than its contributors. Perhaps, too, a commitment should be made to methods to reduce unconscious bias, such as blind submission of code. Without such clauses, a programmer’s oath will only obscure long-standing irregularities instead of freeing contributors to do their best.

Enforcing the Code

As far as I have seen, Martin does not suggest that his oath should be required in any way. Nor has anyone else attempted to enforce it in any form. Instead, the idea seems to be that programmers should commit to the oath individually as a way of demonstrating their aspirations to high standards.

All the same, the question arises of whether oaths or codes of conduct are effective in encouraging certain types of behavior or discouraging others. Many argue that posting a code of conduct sets expectations, creating a safe environment, and freeing people to concentrate on their work. Hundreds of thousands of dollars have been raised and spent on anti-harassment codes alone on this assumption.

However, the assumption is largely unsupported. No conclusive academic study backas this idea. It is simply assumed, perhaps as a matter of wishful thinking.

In fact, considering that the first codes of conduct appeared in the 1990s and were forgotten in a decade, codes of conducts may be nothing more than security theater, making people feel better in the same way that airport security is supposed to, but doing little to solve the problems they are supposed to counter.

Perhaps, then, the main value in codes of conduct and oaths like Martin’s is in their creation. As any writer knows, the struggle to articulate thoughts clearly and concisely is one of the efficient ways to understand them better. Martin’s oath may never be required of anyone, but the discussion of it helps not only to clarify priorities, but also to suggest how far FOSS culture has evolved and how far it still has to go.

---

Cover Image: Compass  by Unsplash for Pixabay.com.

[sharedaddy]