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?

• PRESENT TIME

  Many programmers cannot confront the present-time environment–not necessarily the space that they are in while they’re programming, but the environment that they are designing a system for. Programmers must design only for present-time, fully-known requirements that they have actually discovered by confronting the immediate, real environment that they are designing for. However, instead of this, most programmers enter one of two substitutes for present time: their imagination or opinion about the present time environment, or their imagination about what the future environment will be. In general, it’s much easier for a person to confront their own thoughts about something than it is to confront the actual thing. In software, though, this leads to disaster (and “a disaster” would be how I would describe nearly all of the modern software landscape, truthfully).

  When a programmer uses their imagination or opinions about the present to design a system instead of confronting the current reality to learn what needs to be done, they design a system that does not actually fulfill their users’ requirements. This is why so many programmers think that “all first tries should be thrown away and re-written”–because they couldn’t confront the real environment, so the first system they designed wasn’t appropriate for reality. Then they delivered it to the users, and the users raised hell because the system was worthless or extremely problematic for them.

  When a programmer imagines a future environment instead of confronting present time, they create a system that has features that (a) users don’t need, (b) is far more complex than it needs to be thanks to these unnecessary features, and (c) does not appropriately fit with the real future when it comes. Most programmers think that all large programs will have to be fully re-written at some point, but this is a false datum. These systems that “need re-writing” have been so heavily designed for an imaginary future that when the real future comes, the only workable solution is to throw away the mis-designed system and create a whole new one for the real present. It’s not that all systems need re-writing, it’s that almost every system is plagued by programmers who chose to confront an imaginary future instead of the real present.

• USERS

  Programmers are uniformly excellent at confronting machines, technology, and computers. However, far fewer programmers are excellent at confronting users–the human beings who use their software.

  Now, there is a stereotype that all programmers have poor social skills, but I have found that in my experience this is not true. Most programmers are perfectly capable of having standard social interactions with other people. However, what many programmers do not confront is actually communicating with users about the systems they are designing. Much like with present time, instead of finding a user (or a lot of users) and talking to them, surveying them, etc., programmers will frequently imagine a user and then design the system for that imaginary user.

  Sometimes this imaginary user is very much like the programmer themselves, or like one of the programmer’s parents. No matter who this imaginary user is or how intelligent the programmer is at creating them, though, they are not real. Only real users have real requirements–imaginary users have imaginary requirements that you should not be wasting your time on and complicating your system by implementing.

  In fact, it’s not just enough to confront one user, but to design a truly sensible system, you have to confront lots of users. And you can’t just bunch them all up in a group and then imagine what that whole group of users thinks–you have to confront each person in that group of users individually, and communicate with them as an individual to discover the broad patterns and needs across these individuals that will assist you in designing an excellent system.

• DOCUMENTATION

  The number of programmers who just haven’t read the documentation on things is pretty astounding. Nearly everything there is to know about programming and computers has been written down somewhere, and all you have to do is read it. If you haven’t used some piece of a programming language before, then read its documentation before you use it. Simple.

  The thing that most frequently gets substituted for reading the documentation is copying and pasting other people’s code without understanding it. That is, the programmer could have spent some time reading up on things so that they understood how to do it themselves, but instead they found some piece of code that “just works” and copied it into their system without having actually read any references about it.

  This is less common than the other problems listed, but it’s still a pretty widespread issue.

• NOT KNOWING

  This is actually a broader problem–probably the whole world has been messed up across billions of people and thousands of years by man’s inability to confront the fact that there are some things that he does not know. Instead of simply looking at something and saying, “I don’t understand that, let’s find out what it is,” people will invent explanations and then not investigate. For example, thinking “that person frowned at me, they must dislike me,” without ever asking that person if they actually dislike you. Many people will substitute an invented piece of knowledge like this instead of finding out the real knowledge, because it’s so uncomfortable to “not know” that they can’t do it for long enough to actually find out.

  In programmers, I most frequently see this manifested as the assertion that they do know something about the future when in fact they do not. They are so uncomfortable with not knowing what is going to happen that they imagine a future and then design a system based on that.

  The same problem happens with user requirements–it can take a long time to gather user requirements accurately. Until you’ve gathered them, you don’t know them. But that rarely stops programmers from saying that they already know what the users need and want. Often this escalates into arguments among several different individuals about how something should be implemented, when in reality all of those individuals have absoultely no solid evidence to support their arguments, but only their opinions. Their opinions were easy to confront, but admitting that they didn’t yet know the truth was hard to confront.

  Before you can know something, you have to first admit that you do not know it.

There are probably other things that programmers could use some help confronting, too, but the above are the most major ones that I’ve observed across a broad range of projects and skill levels.

The solution here is to simply train programmers to face these things without flinching or avoiding them, and then you will ultimately have reasonable, sane, simple systems that don’t cause endless trouble for everybody.

-Max

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

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?

-Max

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.

Those of you who read my main tech blog know that I talk a lot about change, so this quote from L. Ron Hubbard made me smile when I read it.

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.

-Max

* A preclear is the most commonly-used term for a person receiving Scientology counseling. The term “preclear” is used because the person is on the way to being a Clear.

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.

-Max

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.

-Max

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. The only rule in that universe is addition. The only objects in that universe are two number 1′s and a number 2. And yet, that’s enough to be a “whole system of created things.”

This becomes especially apparent in larger computer programs, particularly ones where you’re using Object-Oriented Programming. You say “I have a Dog object and a Frisbee object. Frisbees can be thrown, and a Dog can retrieve Frisbees.” You’ve actually just invented a universe–that’s “a whole system of created things” right there.

A word processor is a universe where you type keys and they appear on the page, and there are certain rules about how they are formatted, ways you can make them bold, italics, etc.

In fact, I would go so far as to say that computers are actually universe simulators. This seems to be the most accurate description of a computer that I can come up with.

The very earliest computers could simulate very limited universes–they cracked German coded messages during World War II using some very basic rules. As time went on, they evolved into being able to simulate more advanced universes, such as a word processor or a spreadsheet. Now most people run a universe called Windows on their computer that has little “windows” that contain other universes, like word processors, web browsers, and spreadsheets.

This is probably why games have always pushed the limits of computer hardware more than anything else–because most computer games are directly and obviously universes, and some darn complex universes at that! (Particularly when you start getting into 3D games, the kinds of calculations required to simulate that universe in a computer are pretty intense.)

This is also why I think VR has never been successful–because the job of a computer is to simulate universes that aren’t this universe, not to re-simulate this one. (This is also why AI doesn’t really get us anywhere–because universes don’t think, they just are.)

Anyhow, Scientology 8-8008 has a lot of information on how universes are created, and looking at it, I’ve personally found it applies in really interesting way to writing programs! Particularly the section called The Factors, which deals a lot with the creation of universes.

-Max

To me, at least, this has long been a mystery. Why is it that a programmer, given total understanding of his field, excellent training, and high intelligence, could yet produce better in a more enjoyable environment? It would seem to have nothing to do with the interaction between a person and a machine, as programming seems to be.

Well, in Dianetics: The Modern Science of Mental Health, L. Ron Hubbard talks about pleasure, over and over. One of the things he says is:

There is a necessity for pleasure, a necessity as live and quivering and vital as the human heart itself. … The creative, the constructive, the beautiful, the harmonious, the adventurous, yes, and even escape from the maw of oblivion, these things are pleasure and these things are necessity.

Talk to anybody who worked at Netscape in its early days, and they will tell you that there was a sense of adventure in what they were doing. Talk to some of the people who work on Google’s greatest projects, and ask them about how pleasurable they find their jobs. Ask the Apple engineers how enjoyable it was to create the iPhone, or to design Mac OS X. Ask the world’s greatest user interface designers if the harmony of a perfectly usable, good-looking interface isn’t something that makes them happy.

Or just ask me why I have spent the last four years of my life working on Bugzilla.

The world’s greatest creations don’t come from the desire to make a quick buck, or the fear of a manager’s wrath. They don’t come merely from some programmer’s desire to prove how smart they are, and impress their peers. And they definitely don’t come about from organizations where programmers sit, blank-faced and void of thought, forced to stare at a computer to the exclusion of all else for eight hours a day, deprived of the pleasures of life. No, true creation flourishes in environments that bring into being that necessity “as live and quivering and vital as the human heart itself”–pleasure.

-Max

Goodness and Badness, Beautifulness and Ugliness, are alike considerations and have no other basis than opinion.

I’ve heard many programmers talk about “beautiful code.” Of course, it seems to mean something different to everybody! People can definitely have arguments over what is good or beautiful in code.

Now, most people don’t write code and then think, “Aw, that code was terrible, horrible, and ugly.” Most programmers are pretty happy when they complete a project, and tend to admire their own creations. They might have a terrible tangled mass of code, but to them it might be beautiful. For us, though, who have to fix their terrible, tangled mass of code, maybe it’s not so beautiful.

So what can we do about people this like? Obviously, we know that there are better ways to write code and worse ways, and we’ve formed our opinions based on experience or having read some sensible things and agreed with them. We can’t just let people write terrible code and mess things up. So what do we do?

Well, has anybody ever changed your opinion about something? How did they do it? If you read something and thought it was sensible, and came to see why “good” code was “good”, and “bad” code was “bad”, then perhaps that person could read that thing too! Perhaps you could explain to them gently why you hold your opinions, and give them the chance to change theirs. Perhaps you could show them some good evidence, and they’d change their mind.

At the very least, a little communication probably wouldn’t hurt anybody.

No matter what you choose, once you realize that all that’s happening is you have different opinions, the way is open to do something about it.

By the way, the quote above is part of the “Axioms of Scientology.” In Scientology, “axioms” are:

axioms: Statements of natural laws on the order of those of the physical sciences.

That’s from the glossary of a book called Advanced Procedure and Axioms, by L. Ron Hubbard.

The axioms are numbered, and the axiom above is Axiom 31. The rest of them are all very interesting, and I’d recommend you get a copy of Scientology 0-8: The Book Of Basics, if you want to read the rest of them.

-Max

Only things which are poorly known become more complex the longer one works upon them.

Have you ever seen that happen with a software project? It just becomes more complex, and more complex, and more complex, and eventually it’s just a huge mass of complexity that nobody can maintain anymore?

I think it might be interesting to think about that in the context of the above quote. Perhaps there’s actually something more that could be known about the system. Maybe your users don’t actually need or want all those features. Maybe there’s more research that could be done on different areas of the system. Anything, really–just know more about it. Maybe there’s even some fundamental missing data about life or programming that’s hampering the project.

Whatever it is, I think it’s pretty interesting to think that knowledge could defeat complexity!

-Max