In a policy letter of September 18, 1967 titled “COMPLEXITY AND CONFRONTING”, L. Ron Hubbard states:
To the degree that a being cannot confront, he enters substitutes which, accumulating, bring about a complexity.
The definition of “confront” being used there is a Scientology definition: “to face without flinching or avoiding” (that’s from the Dianetics and Scientology Technical Dictionary).
This is the no-holds-barred, fundamental explanation for why some programmers cannot produce simple systems. This is the underlying difference between the great programmer and the terrible programmer–the degree to which he can confront.
But what is it that these terrible programmers are not confronting that leads to these convoluted, awful systems that we all live with? At first, you might think that it’s the computer, the keyboard, the monitor–the simple, obvious things that are right in front of them. But all the programmers I know have no trouble confronting those things. In fact, many programmers are most comfortable facing a computer, and don’t avoid it in the least. And as L. Ron Hubbard says, people enter substitutes for things that they can’t confront, and programmers don’t substitute other things for their computer. In fact, they’re more likely to use their computer itself as a substitute for other things that they couldn’t confront.
So what are the things that many or most programmers can’t confront, that they enter substitutes for? Read the rest of this entry »
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.
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:
Man is successful. That is evident because he is here today after eons of trial and error, good and bad planning. And he is successful because he can change.
Now, you really should read that whole chapter (Chapter One in the book) for the complete context of the quote. It’s actually quite a beautiful and inspiring chapter–well worth reading. But that quote is enough for what I want to talk about today.
What do our software systems do? They change. The environment changes, requirements change–things change. It’s our ability to change our software effectively that largely determines whether we are good or bad programmers. It’s not our ability to construct a system that “works”–although that’s certainly important. No, what distinguishes the great programmer from the mediocre programmer is that the great programmer writes systems that can be changed.
Granted, just being able to construct a working system can be quite a challenge! When you’re a brand-new programmer, that’s what takes up most of the time–learning the language, figuring out how to do things, just making things work. That’s completely understandable if you’re a new programmer, or if you’re new to some language or technology. But once you’ve got a handle on that, it should quickly (or slowly) become apparent that there’s going to be a future to your code, and that means that you’re going to be changing it. If you didn’t plan for change, that’s going to be tough.
What do I mean by “plan for change?” Well, just have the idea, when you’re writing the code, “this might have to change some day,” and think, “what would keep this flexible, while still keeping it simple?” Sometimes that takes learning more about software design, but it’s always well worth it. The more you program, the better you’ll get at it. Just have “changeability” as a goal, and as you become a better and better programmer, your code will become easier and easier to change. It only becomes a problem if you never even care about it, and just spend the rest of your days as a programmer building spaghetti code that “works” but can never be fixed or changed when needed.
And as a note very related to this, never let anybody tell you, “If you’re not coding, you’re not working!” No! Planning, designing, refactoring, and even a bit of scribbling thoughts on paper are all extremely valuable uses of your time, and should not be neglected. Those are a large part of what help you cope with change. Programming isn’t all typing–it’s a bit of observing, thinking, and talking, too.
In a series of lectures called the Philadelphia Doctorate Course, L. Ron Hubbard says:
All of your work…is motivated by the future, not motivated by the past: you want to eat tomorrow, why, you work today.
That’s from the seventh lecture in the series, on December 2, 1952, for those who are curious. 🙂
So why program? Are we doing it because the boss tells us to? Maybe we’re doing it to eat tomorrow and pay our rent and buy nice things for ourselves. I think a lot of programmers are doing that, and there’s absolutely nothing wrong with that. I mean, it sounds a little unpleasant–working so you can live, while spending most of life at work–but it’s not evil or wrong or something like that. But in addition to all that, aren’t there some people who might take a little pride in their work? Maybe there’s something in the future that we’re working toward–a completed product, a happy user, a piece of software that helps people–something.
Well, that means our software must have a future. And we’re creating that future, right now. In fact, you could go so far as to say that everything we do to the software in present time is somehow motivated by the future. It might be the future five minutes from now, or it might be two years from now. It doesn’t matter how far into the future we’re talking about, it’s just clear that it’s the future that motivates the tremendous amount of thought and effort that we put in to our systems.
We write code now so that we have a working system tomorrow. We put effort into the system now so that it can save us effort in the future. We work on our software architecture so that we don’t have to continually fix our software in the future.
It’s very easy to think of a system as “a series of decisions made in the past that led up to what we have now.” But who cares, because our work now isn’t motivated by a desire to affect the past–you can’t affect the past, that’s a pretty fundamental law of this universe. 🙂
You are the programmer, you are the cause of the system right now, and that cause is motivated by the future, one way or another.
In Scientology: The Fundamentals of Thought, L. Ron Hubbard says:
To stop any creation, it can be established that one once knew one was creating it (finding that thought) and making it known again.
At first, that might seem like a funny thing to apply to programming. After all, aren’t we trying to create programs, not stop their creation?
Well, yes. But there are a few things that we don’t want to create, like bugs, or bad designs. I know I’d be happier if those stopped being created. 🙂 So how can this quote help us?
Well, have you ever noticed that some programmers produce far, far more bugs than other programmers? They just can’t seem to stop creating bugs. Now, these programmers, have they ever thought back to the moment they were making the bug, and found for themselves what decision they made at the time? Have they ever really taken responsibility for having made a decision that caused a bug, or do they just “fix the bug” and never try to understand the source of it?
Many of the greatest programmers I know have an instinct that they should go back and find out where a bug came from. They just know that this is important, even if they can’t quite articulate why (other than the practical sense of “Well, it might also be affecting other things” or “It’s educational”). When they find it, if they caused it, they’ll say, “Oh, yep, that was me.” They might even explain a little of what they were thinking, at the time.
On the flip side of the coin, some of the worst programmers I know spend a lot of their time blaming others for having caused bugs. Whether the blame is right or not, it doesn’t matter, because what needs to be established is “that one once knew one was creating it,” not that somebody else knew one was creating it. You have to find out for yourself what happened!
This whole thing also happens with software architecture. Somebody makes a decision like, “Okay, we’re going to design this poorly because we’re crunched for time.” Then, years later, they wonder why that part of the software is so hard to maintain! They never went back and took responsibility for having made that decision, they just hacked and patched and fixed–in other words, they kept on creating the bad design.
Often, it seems like there’s no way to handle bad designers or poor programmers. That they’re just hopeless and have to be let go or removed from the project. But maybe–just maybe–something could be done about it by teaching them to go back, note “Oh, right, I did have a thought about creating this,” and then get on with making it better or creating something new.
In a book called Scientology 8-8008, L. Ron Hubbard defines a “universe” like this:
A universe is defined as “a whole system of created things.” There could be and are many universes and there could be many kinds of universes.
If you’ve never thought about it, it might be hard to envision the idea of a universe that doesn’t look or act like this one. Here’s a way to think about it: Yesterday, I ran into an abstract artist and I had this thought about her art–I asked her, “If you could create a universe, would it look like this one [the physical universe]?” Instantly, she said, “No!” This is something that I had not understood about abstract art until that very point–that it represents a whole universe made by the artist, not a representation of this universe. Her universe has colors and swirls and represents things in a whole different way than this universe.
So that’s a very wild example of “a universe”–the things that you see in abstract paintings. That’s “a whole system of created things” completely different from the universe we’re used to seeing (the physical universe).
In a much less wild way, a computer program is also a whole universe. For example, let’s take a simple program that adds 1 plus 1 and gets 2. Read the rest of this entry »