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.

-Max