Bob Martin has published the Programmer’s Oath. What do I think about that? The answer may surprise you.

Spoiler Alert: Mentions recent Doctor Who

Updated: Gregory provides a summary of his views

Yesterday, Gregory Brown engaged in a long series of tweets regarding Bob Martin’s “Programmer’s Oath”. I wasn’t able to do justice to Gregory’s thoughts here, but in response to the first version of this article, he has kindly summed them up this way:

Gregory believes #2, #3, #5 come at a significant cost to uphold, both in technical learning time and hard-won understanding of the problem being worked on. Their potential benefits are variable, but the costs are fixed and paid up front.

There are circumstances where maximizing #2, #3, #5 is optimal, with sufficient resources and a sufficiently stable and learn-able problem domain. But when time, money, and stability of the business domain are limited, it’s a matter of finding the right balance between technical optimization and growing your understanding of the business and its customers, and their needs.

In other words, you have to look out for both the opportunity cost of committing to #2, #3, #5 as well as their potential for diminishing returns when considered in the full context of real work on products.

Investing a level of effort in technical concerns that is “fit to purpose” is optimal, and sometimes this means 100% effort on code quality concerns, other times it becomes a more complicated question. Experience, practice, and discernment are the guide that will tell you what to focus on, when.

Do look up Gregory’s twitter stream and read his views there as well. His ideas are well worth considering, and you can see his point. What I’m going to do here is go over Bob’s thoughts and provide my reactions.

Then, since he has kindly provided the thoughts above, I’ll respond to those in a separate article. I think I see some interesting points of difference.

I thank Gregory for triggering this thinking and writing.

Overall

Overall, I am not fond of being asked to take an “oath”, and I am very much not fond of feeling that I’m being told what to do. As such, I find many of my friend Bob’s talks and writings to be more preachy, didactic, and dictatorial than I enjoy. Those are matters of style. Plenty of people don’t like my style either, and that’s the way it goes: we pick a style that we hope will have the impact we want on the people we’re trying to reach. I try to read past matters of style and understand the meat of what people are saying, and I commend that notion to you. Start with this article, please.

As for the content of the Oath, let’s look in detail. Gregory objected to Numbers 2, 3, and 5 particularly, so keep those in mind.

1. I will not produce harmful code.

On the surface, this seems reasonable. And yet, in my youth, I worked for Strategic Air Command in a civilian capacity, and the code I wrote would have been used in the event of the prosecution of a nuclear war. It is difficult to imagine code that is potentially much more harmful than that. Yet I happen to know that the people in that line of work understood better than anyone how awful such a war would be and were doing their best to ensure that one never happened. They felt, and I felt, that our work was quite moral.

I don’t know whether I’d take that job today. Quite possibly I would not. But I can understand why someone would and I consider that kind of thing to be a matter of personal morality.

That said, by and large, I agree that code should not be harmful to anyone or anything.

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.

This is a principle I believe strongly, especially the first sentence. I do think that my best work at any given time is rarely as good as my best work ever: like most people, my abilities and skills are uneven. I hope my best day lies before me, but looking back I can see days when I was probably better than I am right now.

Have I ever released code with no known defects? Yes, I have. Have defects ever shown up later? All too often. But the Oath says “knowingly”. What about releasing code with known defects? Yes, I’ve done that too. I think I’ve always tried to be clear with the decision makers about defects, but it is their call to release with known defects if they want to. And sometimes it can be a good decision. A program that gets the right answer 90 percent of the time and crashes 10 percent could be quite useful.

But what about the principle behind the words? Do we ever want to write a defect? I don’t. Do we ever want to ship with bugs? I don’t. So I agree with the idea but don’t think I can, or even should, live up to the letter of this law.

As for structure, I’d want to know what “defective in structure” even means. Incapable of improvement in structure? I’ve never seen a program that couldn’t be improved at least a little bit. Again, I want the structure to be good – really good – and I don’t know how to live up to the letter of the law.

3. I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.

I’m guessing that this calls for tests, TDD-style tests and acceptance- or customer-style tests. I agree in principle, and yet … my skills are such that I don’t always know how to produce that kind of “repeatable proof” that things work.

We could also quibble over the word “proof”. It is generally impossible to prove that a program works. What we can do is provide examples and show that for those examples the program seems to work. Sometimes, very rarely, we can do a formal proof of some small part of the program. If you ever did proofs in math class, you know that your proofs often had holes in them even when the theorem was true. The same is true of proofs of computer programs, in the rare cases where they’re possible at all.

There are also some things that I know in principle how I might test but in practice the tests would take too long – weeks or months – to write or run. So in practice, I can’t always do this.

I don’t know how to live up to the letter of this law. I agree with the principle and cannot swear to do it because I’m not that good.

4. I will make frequent, small, releases so that I do not impede the progress of others.

I can get behind this entirely. I generally know how to do it, and I believe that it’s always possible. I can think of no reason why I wouldn’t do this.

5. I will fearlessly and relentlessly improve the code at every opportunity. I will never make the code worse.

I am on board entirely with the first sentence. Every time I touch the code, I try to make it better. I know how to code and test so that I need not fear such changes.

As for the second sentence, I can think of at least one exception. In some code I’m writing just now, there is a “virtual machine” inside the program, with a little language. The machine has many operation codes. The implementation of these, inside, is a series of if statements:

if op == "this" do this else if op == "that" do that

… and so on. Every time I add an opcode, I have no choice but to extend this long list of ifs. And I do mean “no choice”. The language in question does not have function pointers or classes. There is no cleaner way. So this code gets a bit worse every time I add a feature.

I do not have the ability to rise to the level of this rule, much as I’d like to, and as much as I try. That said, where I have the ability, I am ready to live by the rule.

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.

In principle, I agree. Yet, earlier this morning, Chet and I discussed Clara’s death and how it fit into the overall new Doctor Who sequence. It may have helped with our bonding, but it almost certainly decreased my productivity, in that I didn’t start on this article until after that chat was over.

Did that chat interfere with my productivity and Chet’s? I don’t know, and I don’t care. Life is too short to stay heads down all the time.

I like the principle and think the rule is very poorly stated, requiring me to quibble over the word “productivity”. I am not inclined to sign up for this rule.

7. I will continuously ensure that others can cover for me, and that I can cover for them.

I think this is a good principle. In a team situation, I’d want to use pair programming to make it happen.

There is something that pushes back against this idea for me, and it is the desire that many of us have to just once in a while make something all by ourselves. I have that feeling, and I think that others probably do as well. I don’t think this has to get in the way but I mention it as a caveat.

8. I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.

I’m down with the second sentence. I’m not very good at making estimates that are any good at all, and I am in spirit a #NoEstimates person.

But if I were going to make estimates, I agree that they need to be honest and I’d try to measure up.

9. I will never stop learning and improving my craft.

I sure as hell hope so!

Summing up

I am in pretty solid agreement in principle with every single one of these. I emphasize “in principle”, because I have issues with some of them:

Issues

For numbers 2, 3, and 5, the same items that Gregory was primarily concerned about, I freely grant that I have neither the skill nor the stamina to live up to the “always” part of these rules. I do believe that all of the implied practices make me go faster, so that the only excuse I have for not doing them is that I’m not good enough. While I might ship with a flaw in the code, I do not believe that there’s improvement in progress to be made by dialing back on learning, or using testing and refactoring skills.

Differences

So do Gregory and I differ? I believe so. If I understand him, he believes that, at least for items 2, 3, and 5, we really shouldn’t strive for perfection. I never expect to attain perfection, but I can think of no value short of perfection that I could recommend instead. So I find Bob’s items to be good when seen as aspirational values, even though I cannot in conscience take an oath always to do them, because by tomorrow morning, I’d have broken my oath.

Bottom Line

I am left with a very odd feeling about this “oath”. I cannot possibly live up to it, and among all the programmers I’ve met, who surely must number in the hundreds if not thousands, I know of none, zero, not any who could live up to it. That includes Bob Martin, who is one of the top programmers I know. It is not given to us to be perfect, and I do not recommend that anyone take an oath to do what they cannot do. In fact, Rule 8 requires us to be honest in our estimates of our ability to deliver and that honesty requires us not to take the oath.

I’d like to see these ideas rewritten as aspirational goals. I could support every one of them entirely in that form. In the form of an oath, I think they’re over the top. Not that there’s anything wrong with over the top: I rather enjoy it myself sometimes.

Thanks for the topic, Gregory! I hope that you, and everyone, enjoys the result.