New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Uncle Bob Proposes an Oath to Programmers

| by Abel Avram on Nov 28, 2015. Estimated reading time: 4 minutes |

Uncle Bob proposes an oath to software programmers as other professions have, considering the importance of this craftsmanship.

A year ago, Robert C. Martin, a.k.a. Uncle Bob, noticed the importance of the software programmer, writing:

We rule the world. …

Nothing happens in our society without software. Nothing….

Without software: Phones don't ring. Cars don't start. Planes don't fly. Bombs don't explode. Ships don't sail. Ovens don't bake. Garage doors don't open. Money doesn't change hands. Electricity doesn't get generated. And we can't find our way to the store. …

Martin went on observing that having such a great role in the society programmers should be responsible and follow a code of ethics, to use the power they have for the good of the society. Programmers should decide what is to be their responsibility and it should not be imposed on them by the government or the employers. And he sketched a code of ethics inspired by the Order of the Engineer. A year later, Martin writes again on ethics, this time more about the quality of the code written, proposing The Programmer’s Oath that every member should take to “defend and preserve the honor of the profession”:

  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.

Martin’s proposal had various reactions on Twitter, from:

@klenkes74: my assumption is that my employer will fire me if I live strictly by that rules.

@QuiteVague: Most programmers are in no position to commit to these- the balance between quality and business needs isn't in their hands. … I've raised almost every one of these to a variety of managers. And, as I've said, you win some, you lose some :)

@DamienPetrilli: very utopian, totally not applicable in the real world for most.

@asthasr: #9 is the only valid one. Others are impossible ("proofs") or rely on external factors over which we have no control.

@sleepyfox: I would argue that 8. is impossible to uphold, due to inherent uncertainty. An estimate is at best a guess, not a promise.


@brianvhughes: #5 is a hope, at best. #8 is impossible. But, it’s not all bad

@simonbrown: "I will never stop learning and improving my craft." <- yes!

@Khris_Fernandez: I would love we all sign this in every project I work on from now ! Sadly, some will never do. Anyway, thanks Bob.

@GGrell: I laughed, I cried, I rejoiced. This is some of what I strive for writing software every day.

Answering to some of those not convinced by the need of an oath, Martin argued that software engineers should have ethical responsibilities, and like doctors, lawyers and engineers they should have an oath which is “dogmatic by definition”.

On the same note, the founders of Rugged Software have written a few years back The Rugged Manifesto, a collection of principles that programmers are invited to abide by:

I am rugged and, more importantly, my code is rugged.
I recognize that software has become a foundation of our modern world.
I recognize the awesome responsibility that comes with this foundational role.
I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended.
I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic and national security.
I recognize these things – and I choose to be rugged.
I am rugged because I refuse to be a source of vulnerability or weakness.
I am rugged because I assure my code will support its mission.
I am rugged because my code can face these challenges and persist in spite of them.
I am rugged, not because it is easy, but because it is necessary and I am up for the challenge.

With an oath or not, following the lines of a manifesto or not, perhaps everybody agrees that all software engineers should aim at writing good software. What that means and how to achieve it is another story.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Doomed to fail? by David Dawson

I think this is a nice idea, but isn't going to change the world.

The problem is not one of intent, I believe that this is done with the absolute best motivation, however I am certain that what will actually end up happening is that this will be turned, subverted even, into a stick to beat the unwary developer.

You signed an oath!

This isn't the first time we've been around this particular roundabout.

Riffing on star wars, you could tell the story of the past decade ...

Where were you when the agile wars were fought?

were you part of the craftsmanship rebellion against the Scrumpire?

here are the XP practices of your father, elegant tools from a more civilised age

I could go on.

The point is that we have seen dogmatic positions taken, manifestos issued, revolutions in software development proposed, abandoned and then made anyway for reasons no one can quite fathom. It's been a fun time, if wierd at certain points.

What we can do now though is look back on the past decade and see what this has resulted in, and if we actually want more of this.

It all started with XP. A set of developer practices and associated was of doing things. Apart from the silly name (really guys?), I can't detect any real belief system associated with this. It's a way of doing tech better, but not fundamentally making you a better person while that happens.

Different movements, ideas and belief systems came after this, but they all seem to want to improve the state of the developer as a person. Imbue some belief system, some mode of thought, some new philosophy.

This is not something that can be objectively measured, or analysed in a way that can be proven either way. It's a statement of belief.

This is the rub, and why I think this is doomed to failure, as it is, at core, another set of beliefs for software bods to absorb.

We've seen this type of thing happen in both software, and elsewhere, and the result is always the same. Firstly a section will adopt the belief strongly, another section will not. Next, positions will become more defined, and there will be less crossover between the groups. Then conflict starts to happen. The original idea of improving the state of software development is lost in the midst of this.

The Agile Manifesto is a good example of this process in action. It is at the point now of being taken as a self evident truth by many, beyond question even. Invoking it is a way to win an argument simply by appealing to an unnassailable authority.

This is wrong. It is dogma, it is religion (in the negative sense of the word, unquestioned belief). We can do better than this.

I could go on, but my point is made. I expect this oath to become dogmatic if broadly adopted, and that cannot be good for the general state of software development.

Thus, the original intent, while laudable, can't be met by invoking a statement of belief.


There is no balance between quality and business needs by Xing Yang

Quality is the only thing that matters. Doctors won't prescribe a drug knowing it'll kill a patient. Civil engineers won't open a bridge knowing it'll collapse in the near future. Yet we the software engineers are putting doggy software into every possible places, including life-critical equipments. It's a shame for members of this profession coming up with all sorts of excuses not to pledge the oath.

Employers insisting on poor software for short term profit should be denied of being served by us.

An alternative by Jeff Hain

I prefer Ben Gracewood's company values:
- JFDI (just f*ck*ng do it)
- DBD (don't be a d*ck)

(cf., 3m)

until business guys give a crap by peter lin

it's not going to happen without non-technical business users buy-in. For open source projects where developers have 100% control, I try to follow those principles. Most business projects the deadline is everything. It doesn't matter if it's a bad idea, impossible or just stupid, business users will demand programmers hit the deadline. They don't have to build it or maintain it, so they don't care. It's like hotdogs. People just want to eat it, but they don't want to know how it's made.

Good idea, not so good in execution by Arturo Hernandez

I just read the Hippocratic Oath.

I think this oath in comparison to Uncle Bob's is a more humane and principled. That Hippocratic oath does make want to be a Doctor. It recognizes that we are fallible humans after all.

This other Oath makes me want to go to a doctor of Psychiatry. Although I do appreciate Uncle Bob's honest effort.

Re: Doomed to fail? by Richard Clayton

I love this response. Thank you.

Re: An alternative by Louis P. Santillan

First is the Nike slogan modified for the unnecessarily verbally aggressive millennials while the second is Wheaton's Law. However, if you boss or manager is giving you the first, he might have a conflict with the 2nd.

To the naysayers by Stephan Schwab

People usually have good intentions and that includes business people. The issue is that people in larger organizations are frequently driven by different objectives and/or judged by different criteria.

Example: if your boss' performance gets judged by projects being delivered on time and budget, then you are not helping him by doing things that seem to cause delay.

On the other hand things like collective bargaining - to name a powerful example - have changed the business world. Naturally all good things can also be abused. So let's not pick on the edge cases.

There is also a smart way of saying NO by offering alternatives and trade-offs. Unfortunately, many technical people never learnt that and think and behave quite digital (1 or 0). In business there is a lot of grey in between things and learning about how to navigate in a complex situation is certainly helpful. As an Agile Coach I try to do my part to help people with that.

Re: There is no balance between quality and business needs by Ryan Gardner

What determines if the code is quality code? if it's got valid unit tests? If it's got 100% line coverage? If it's got 100% line and branch coverage? If it's got a regression suite? If it passes a load test? if it passes a load test at 2x the expected load?

Doctors actually DO prescribe drugs when they know there is a _chance_ that there will be negative side effects if the situation warrants it.

Civil engineers DO open bridges that meet a certain minimum standard and may collapse if a convoy of tanks drives over it.

The problem is there are plenty of software engineers who get really hung up on "quality" and try to build bridges that can support a convoy of tanks when what is needed is simply a foot bridge.

These kinds of engineers are also the kinds who would be really into this kind of oath.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

9 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and dont miss out on content that matters to you