My Response to Uncle Bob’s Oath

I ran across Ron Jeffries’ comments on Robert C. Martin’s (Uncle Bob) “The Programmer’s Oath”, and thought I would add my thoughts.

Like Ron, I find a lot to like about Bob’s “Oath,” and I have reservations and issues with parts of it.

With strong statements of things that are claimed to be “good” or “the way things should be,” I often find it helpful to consider what things would be like if we valued the opposite of the claims: If “be polite to all people all the time” is a value, can we think of counter-example situations where other types of behavior are more appropriate? If so, then we might want to reconsider the claimed value.

On “The Clean Code Blog”, Robert C. Martin (Uncle Bob) proposed “The Programmer’s Oath”, where…

“In order to defend and preserve the honor of the profession of computer programmers,
I Promise that, to the best of my ability and judgement:”

[I will do the following nine numbered things…]

1. I will not produce harmful code.

Now how often do your customers or employers ask you to produce harmful code?

Certainly, when we are in the business of writing software for missile systems, then we should expect that our software will produce harmful results. And if we write software for a an unethical business that harms people as part of its business strategy for producing profit, then we can expect harm.

And it does seem that otherwise ethical and well-meaning customers and employers may ask us to risk harmful results by rushing software production and compromising quality and testing, in order to achieve other generally desirable short-term results, such as budget or schedule goals (…which may be linked to bonus payments, for example).

But I consider it professionally irresponsible to knowingly or carelessly produce software with high risk of unintended harm. I consider it a professional responsibility to have and use my specialized knowledge and experience to ensure that the software I write performs the intended functions, with little risk of unintended harmful outcomes. While risk cannot be absolutely eliminated, I think there are reasonable levels of “due care” that we should be expected to apply, to be considered professionals.

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.

I find it interesting to try to imagine a case where a responsible project leader would pull aside some project members and explain, “Look; we don’t really want you doing your best work here. We’d really like it if you were sloppy and careless. And we want to release code to production that is defective — full of bugs and unmaintainable.” Something would have to be seriously wrong with the organization, project, or leader for anything like this to happen. And believe me, if it did, it would be a strong indication that it’s time to update one’s resume and go search for a new job — and pronto!

I think most sensible leaders, customers, and employers, would like their people to produce their best work — correct in behavior and structure, to the best of their ability. Now we’re all human. So we’re never going to actually achieve that goal. We might be sleepy or distracted at times, for example. But I believe that these are worthwhile goals to strive for.

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

Like others, I have an issue with the word “proof,” as the practice of doing formal logical proofs has shown itself to be extremely time consuming and expensive, even in the few cases where it can be used at all. And formal logical proofs are not infallible, as they may contain errors. And even if the proof were to be perfect, the specifying the requirements in a sufficiently formal form for proofs to work may make them sufficiently technical that errors or “bugs” in the requirements specifications could be just as bad or worse then carelessly coded “bugs” in conventional software.

I think that “quick, sure, and repeatable proof” is a reference to automated regression testing. In my experience, test-driven development is the best way to produce software. But while most of the industry has adopted “agile,” I find that much of the industry is not willing to go all the way to TDD.

So as a professional, I think it pragmatic and realistic to expect that a professional software developer will produce each release with reasonable verification that it performs as expected, and will continue to do so in the future, if maintained with equivalent care. I think my expectations are compatible with TDD. But when the customers expect and direct the project to lower standards, then I would expect the results could be correspondingly worse.

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

Frequent milestones of “releasable” software are compatible with “embedded system” requirements of having a single “drop dead hard” release date, where “everything” must be present and fixed, with no reasonable possibility of future software changes (at reasonable expense).

And frequent milestone releases provide many more benefits than to just “not impede the progress of others.”

I think item #4 really undersells its own point.

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

I believe in the motto of “leave things better than you find them,” or “always improve things,” or “never make things worse.”

There may be corner cases where this does not work. But I think this is a good rule, even if there are (rare) exceptions.

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.

Productivity is not the only value. Nor is it necessarily the most important.

I find that it is nearly always necessary to take actions that reduce productivity in the short term, to improve it in the longer term. And by “short term” and “long term,” I am often talking about hours, days, or weeks — not “imaginary times in some hypothetically distant future.”

Maximizing the productive results produced with our resources, without destroying said resources, is highly desirable.

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

It would be irresponsible of me to make the success of the project or the enterprise depend on me, long term. I could get hit by a bus. (And I have never really had any intention to “make a career” of any particular project.)

It is responsible and professional to take reasonable steps to ensure that the project and the enterprise can continue successfully, even after my departure. …even if my departure is sudden and unexpected.

And, as a leader, I should ensure the same for all other project members.

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

I believe strongly in telling the truth. Honesty is very important to me, personally.

But I personally have issues with the “certainty” claim. Personally, I don’t believe that anything can be known with absolute certainty. So if I adopted the last sentence in #8, then I could no longer make any promises under any circumstances.

Or, at best, I could only make promises with cavorts, such as “if these conditions hold, then …” But that is probably the best that anyone can do in reality.

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

I think I do have issues with some few of my coworkers who seem to show little interest in such things. :-/

Personally, I find it unimaginable to do otherwise.

Comments are closed.

%d bloggers like this: