There Are No Laws Of Programming

In Webster's New World Dictionary (2nd ed. 1978), there are 13 definitions of the word law. Excluding all the definitions related to legal/judicial, religious, and sports, we have these: "8. a) a sequence of events in nature or in human activities that has been observed to occur with unvarying uniformity under the same conditions: often law of nature; b) the formulation in words of such a sequence [the law of gravitation, the law of diminishing returns]; 9) any rule or principle expected to be observed [the laws of health, the law of grammar]; 10) inherent tendency; instinct [the law of self-preservation]; 12) Math., Logic, etc. a general principle to which all applicable cases must conform [the laws of exponents]."

The software industry is too young to know any particular principles solidly enough to declare any "laws." We are still exploring and learning, trying different paradigms, methodologies, languages, and other tools.

We have grown and developed some reasonably good skills and knowledge, and some of us are pretty pleased with ourselves for this. Some of us are starting to try to make bold statements about what we think we understand about building software, and a few of us are naive enough to think these might be "laws."

But they aren't; they are merely theorems, observations, tendencies, heuristics, and so on at this point. Maybe in another fifty or a hundred years, we'll be a better position to start discussing "Laws Of Software Engineering."

Consider "9) any rule or principle expected to be observed". I think we do have rules or principles that are expected to be observed in software development. This is, by far, the most common use of the term law, and would seem to contradict the title of this page.

I see three broad categories to which the word Law is applied

1) Laws of Nature - these are models which tell us what the effects of a given cause will be, if certain assumptions hold true. They are usually formulated based on observation. If an observation does not conform to one of these Laws then it is probably because the assumptions were not true

2) Civil and Criminal Law - these represent what the Legislature of a particular state hold to be acceptable behavior for subjects of that state. Failure to comply will attract sanction by the Executive of that state, usually after interpretation by a Judiciary.

3) Natural and Moral Law - Natural Law is believed by it's proponents to be innate to all Humans - the internal guidelines which cause us to view certain behavior as good. Moral Law expands on this, usually based on Divine Revelation. It's proponent's would contend that failure to adhere to Moral Law will cause the subject not to attain it's full potential.

It seems to me that the Laws of Programming fall somewhere between these three definitions! AonghusOhAlmhain

In other words, they aren't laws at all. Actually, what I meant is that they have elements of each of the above

I don't believe this maturity business. We programmers have forgotten more in fifty years than "software engineers" ever knew. My first law of software engineering is follow the money: 1. state cuts back on funding for university, 2. university administration demands computer science department serve the business community (so as to get local money), 3. business executives ask for engineering discipline where programmer's work is as predictable as assembly line, 4. faculty creates terminal masters in software engineering and staffs it with adjunct professors from local industry, 5. these guys rummage around for some curriculum and find something made up by someone who misunderstood what civil engineers do, 6. industry finds productivity drops precipitously and confuses the poison for the cure, 7. everyone involved finds that if they just sing this party line that the money keeps circulating. The software engineering crowd would have done better teaching anything by, say, ChrisArgyris, or anyone else who understands knowledge based activity. -- WardCunningham

Ward, don't get hung up on the term "software engineering." It sounds like you've seen some shabby academic programs; I haven't seen them directly, but I've definitely run into the results as coworkers who can't program their way out of a paper bag. I tend to use it because it sounds better than "programming"; because I feel that what I do involves more than slinging code. My degree was in "Computer Science." But I feel that I learned most of what I use on a day to day basis myself, more in the spirit of hacking and pragmatism. After 25 years, I know what works, and I don't let myself get tangled up by any particular methodology, language, diagram, or whatever.

I wouldn't call the programs either shabby or academic, though I would say misguided and uninformed. An experienced developer was telling me just last week that his new boss, a young woman, had asked for a day by day list of tasks and had protested when he added two weeks for unspecified clean-up. He argued that his 25 years of experience had shown that such was always required. She said no way and offered as her credential a newly minted Masters in Software Engineering Management.

So, to get to the point of this page, do you feel that people building software (whatever term you want to use to refer to them) have gained enough fundamental understanding of what works and what doesn't to start declaring absolute "laws"?

I wouldn't use the term "law" either, but I find RodneyRyan?'s observations pretty close to the mark and worthy of more than superficial ridicule.

I'm sorry you perceive my comments about "laws" as "superficial ridicule" -- I certainly didn't intend it that way. I feel it is important that a good concept be phrased as carefully as possible. It is human nature that many words come with lots of baggage, so an unfortunate choice of words can end up limiting the understanding of a very good concept. Personally, if I put something up here that is poorly conceived or written or doesn't make sense, or could be improved by rephrasing (yes, including this page!), I would hope people would say so. (In fact, this has already happened... I consider it a strength of WikiWiki.)

Suppose there were laws of programming and I broke one. Who would stop me? The programming police? -- NickBensema

I guess law in this sense is a broad generalization of reality. No one will get into trouble for breaking MooresLaw, or the LawOfGravity?, though I have heard arguments for repeal of the latter. -- DavidBrantley

To break Ryan's laws you would have to code carelessly and find that this made your work go faster or you would have to find a mature design in your documents while monkeys typed the code. If either were to happen I'd check the radar gun. -- WardCunningham

I don't mind if you go faster than the speed of light. Who's going to stop you?--ApoorvaMuralidhara

Much of what JerryWeinberg has written, including Secrets of Consulting and the Quality Software Management set uses Laws as organizing principles around which to better understand the complex systems we're dealing with. Jerry uses somewhat comical and unusual names for some of these Laws (cf. LawOfRaspberryJam), in order to help himself (and us too) remember them better. As a trained physicist, this seemed the natural thing for him to do. The Square Law of Computation, is a natural law which helps explain much of the difficulty of large software systems development.

A programmer's experience is inverse to their fundamentalism. They know their only limits are computer science and karma

8. a) a sequence of events in nature or in human activities that has been observed to occur with unvarying uniformity under the same conditions

If you don't make a special effort to keep the structure of a body of code clean as things are added to it, it doesn't stay clean. That is, structure degrades unless effort is made to preserve it.

If that phenomenon is not a law of programming (in sense 8a), I don't know what is.

If you're developing code and value it being clean, that leads to a law of programming (sense 9): make an effort to keep your code clean. (The reasons you value clean code may be laws (8a) of their own: e.g. cleaner code requires less effort to modify; cleaner code requires less effort to test; etc.)

See FirstLawOfProgramming, SecondLawOfProgramming, TheyreJustRules, ShuHaRi