Complexity and Confronting






So what are the things that many or most programmers can’t confront, that they enter substitutes for? Read the rest of this entry »


Authoritarian Software Design

In Advanced Procedure and Axioms, L. Ron Hubbard states:

Factors introduced into a problem or solution which do not derive from natural law but only from authoritarian command aberrate that problem or solution.

In this context, “aberrate” means “[to cause to] depart from rational thought or behavior” or “to make something diverge from a straight line” (those definitions are from the Dianetics and Scientology Technical Dictionary).

In my other blogs (Code Simplicity and my personal blog), if you read them, you may notice that I have a rather poor attitude toward various software design “methodologies”, such as “Agile” or “Extreme Programming”. The attitude comes not from these methodologies being totally wrong–there are parts of them that are right, for specific circumstances. My anger comes from the fact that these methodologies are so often used as authoritarian pronouncements as to how a piece of software is going to be developed–they become a “blind faith” method of software engineering. Also, they are incomplete and sometimes incorrect, because they don’t describe natural laws, only methods of operation.

There is no science of software design in existence and broadly-known, currently, which opens to door to anybody coming along and dropping any authoritarian pronouncement that they like into the field, with an abnormally large number of developers only too eager to slurp up the statements on faith to fill the vacuum of data that exists in software design.

There are few engineering fields more full of authoritarian commands than software. One would expect that somebody would have developed a reasonable science for it all by now, but it doesn’t seem to be the case. Instead, random, authoritative pronouncements about software seem to be the content of almost every book, blog, and paper on the subject. I’ve even heard people say that computers are unknowable because they “operate beyond the limits of our understanding,” as though they were some mystical thing that could only be understood through magical insight, or something.

This doesn’t make everybody wrong about software design, and it doesn’t mean that processes or natural laws are unknowable. Data about software design can be true, when correctly studied, tested, and proven. What this all does mean, though, is that when reading about somebody else’s ideas on software, you have to ask yourself–does this idea of theirs derive from natural law, or only from authoritarian command? And if your project is departing from rational thought, you may want to ask yourself–at some point, did we buy an authoritarian command instead of relying on a natural law? And if so, what is the law that we should be following instead?

Sometimes there aren’t natural laws known about an area, and you have to guess at one or figure one out for yourself. I’m currently working on a book that should help explain the natural laws of software design, but that doesn’t mean that I’m the only one who can figure this out or know it. You can find out the natural laws just as well as anybody else could, provided that you do a good, thorough investigation and don’t buy any authoritarian commands as truth. It may seem so easy to buy authority and so hard to do the research, sometimes, but it’s the difference between staying sane with the project and the painful, draining insanity that has viciously destroyed so many otherwise-promising software projects throughout history. You, your co-workers, your managers, and your customers will all be happier with the sane, straight-line solution than the craziness and failure that results from the “quick fix” of authoritarian command.


Programming Languages

In Self Analysis, L. Ron Hubbard says:

Language is quite acceptable when understood as a symbol for the act and thing. But the word “ashtray” is no substitute for an ashtray. If you do not believe this, try to put your ashes on the airwaves which have just carried the word “ashtray.” Called a “saucer” or an “elephant,” the object intended for the ashes serves just as well.

Have you ever thought about the fact that a programming language is just a representation of actions? (In actual fact, it’s a representation for a structure of data, actions taken on that data, and the results of those actions.) It’s just symbols. It doesn’t matter if we call a symbol “goto” or we call it “elephant,” it’s still going to be doing the same thing. And it’s not those symbols that are the actions, they just represent the actions.

It’s easy to become immersed in the complexities of programming languages, and to lose view of the fact that a computer program is there to do something, and that is the only reason it’s there. A computer program is not in fact “a bunch of code,” but is actually a series of actions performed by the computer, and the code is just a representation.

When you write a shopping list, you are giving yourself instructions about what to buy. The actual activity of shopping involves walking through the store and picking those items off the shelf. If you just wrote the instructions and called it a day, you wouldn’t be shopping. The instructions are a symbol for the action, not the action itself.

Similarly, a “bunch of code” is not a computer program, it’s a representation of a computer program. That’s kind of an interesting thought, isn’t it?



In Handbook For Preclears*, L. Ron Hubbard writes:




















Stopping a Creation











How is a Program Like a Universe?




