Where is the source for Niman's 13 Minimally Sufficient Commandments?

Question

I have a page (page 1), dated February 2, 1989 that my former boss presented to me, outlining Niman's 13 Minimally Sufficient Commandments for programming. (He recognized that they were dated, making this more of an archaeology piece than a modern set of guidelines.) If you haven't seen them, they are as follows:

1. Thou shalt adequately comment thy code in order to explain what thou intendest. Man does not think by mnemonics alone.
2. Thou shalt equate numeric constants to meaningful symbol names. Speak clearly and avoid pagan icons.
3. Thou shalt describe all inputs and outputs in thy modules. Be kind to thy software brethren and sistren who may have to maintain thy modules.
4. Thou shalt adequately describe thy revisions. It is a sin to expect your peeren to be mind-readers. Mind-reading is a sin anyway.
5. Thou shalt provide pseudocode explanations of thy assembly code. Verily, assembly is not Cobol.
6. Thou shalt have only one entry- and one exit-point per module. He who has many entry- and exit-points shall expect their bodies to develop same.
7. Thou shalt design thy code prior to developing it. Verily, indeed.
8. Thou shalt conduct reviews of thy code with thy peeren. Blessed be the meek, for they shall inherit the object code.
9. Thou shalt document thy design and make the documentation available to all who maintain the code. Verily, he who refuses shalt debug forth operating systems forever in hell.
10. Thou shalt be able to accept meaningful criticism of they code. If thou art ashamed of thy code, thou should become a professional bowler.
11. Thou shalt throughly (sic) test thy code prior to placing it into library control. One part left out of the Bible was where Job was tested by God by having to debug a large 8096 assembly language program that was part of a disel engine controller. The entire thing was not tested before release. To make things worse, Job had to use Intel tools.
12. Thou shalt avoid the use of global data structures, wherever possible. Towers shalt be named Babel, programs should not.
13. Thou shalt use high-level language when thy assembly programmers cannot match the efficiency of optimally-compiled, late twentieth century code. Beware of false gods who think that assembly is always more efficient (with respect to speed and size) than what good compilers can produce. Thou must be very good with design as well as coding to really take advantage of assembly language.

I've scoured the internet has revealed nothing as to the source of these commandments, or that of Niman, and it's been killing me trying to find out more about this and any other bits he might have had to say. The only other clue I have is that in the lower left, there are the initials "DEN" - I assume N is for Niman, but I have nothing else to identify the text. So,

A. Who is Niman? (Programmer? Teacher? Consultant? Random guy at a company?)

B. What was this page from? (an old programming guide? some company manual? Some BBS back in the day? )

C. Where's the rest of it? (Is there more? What else is there? Was this a stand alone thing?)

In response to the comments, my boss has since passed on, but before that, he was in the biz for a long, long time, greybeard and all. By the color of the paper, I'm fairly certain that the date (1989) is an roughly an date of when it was printed.

Answer 1

I agree with Nosredna - I think your boss wrote it or cobbled it together from multiple sources.

But I felt Inspired to rewrite some of them:

1. Thou shalt write code that can be read without the need for comments.
2. Thou shalt equate numeric constants to meaningful symbol names within reason. x > ZERO is not reasonable.
3. (as is)
4. Thou shalt use source control and not place revision comments in the source.
5. Thou shalt not write Assembly unless thy name is Steve Gibson.
6. Thou shalt use guard clauses and exceptions when appropriate.
7. Thou shalt design thy code, but TDD is design.
8. (as is)
9. Thou shalt not create documentation without reason, nor shalt thou allow documentation to become outdated.
10. (as is)
11. Thou shalt insure that thy code compiles and that thy unit tests exist and pass prior to placing it in source control. Boils may be inflicted upon those who break the build.
12. Thou shalt avoid the use of global data structures, wherever possible. This includes Singletons.
13. Thou shalt avoid optimization without profiling, confession, and self-flagellation.

Answer 2

There's a decent chance the man was Donald E. Niman.

• When searching for Donald E. Niman, you get several results:

  • He was a Software Engineer at Safetran Systems Corporation in Rancho Cucamonga, CA
  • He was active with BOINC doing SETI@Home around 1999
  • He had a few active posts in a couple math forums
  • He had one post in a guestbook on a site for collecting Soviet Calculators (you might need to Google cache that one as it wouldn't load for me)

• A search for "Donald Niman" shows:

  • He is currently in Phoenix, AZ according to Facebook
  • His Google Profile shows that he indeed lived in Rancho Cucamonga
  • He has a single 51 year old friend on Plurk - so he is probably in that age range as well, consistent with writing a little "commandment list" in 1989
  • Name placed on a microchip going to space

This research does seem terribly "stalker"-ish, but given these few details about the man, he certainly matches the persona of someone who would write up some "programming commandments".

He does have a couple points of contact that you can get online - you might be able to get a hold of him and find out if he's the real author. Also, you might be able to tell if he lived in a city where your former boss may have worked in 1989, from his Google Profile page.

Answer 3

The Donald E. Niman found by Mark is the correct one. I should know because it's me. That is a 22 year old thing that I wrote while I was a Cummins Electronics, Inc., in Columbus, IN. It is a bit outdated and I've learned things since then so it should be taken for the proverbial grain of salt. Donald E. Niman, Phoenix, AZ.