Complexity and Confronting

Posted: February 2, 2011 | Author: | Filed under: General | 10 Comments

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 »

Authoritarian Software Design

Posted: December 31, 2009 | Author: | Filed under: General | 1 Comment

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

Programming Languages

Posted: July 12, 2008 | Author: | Filed under: General | Tags: , , , | 2 Comments

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?

-Max

Change

Posted: April 23, 2008 | Author: | Filed under: General | Tags: , | Leave a comment

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.

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.

Future

Posted: April 2, 2008 | Author: | Filed under: General | Tags: , , | 4 Comments

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.

-Max

Stopping a Creation

Posted: March 10, 2008 | Author: | Filed under: General | Tags: , , , , , | Leave a comment

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.

-Max

How is a Program Like a Universe?

Posted: February 16, 2008 | Author: | Filed under: General | Tags: , , , , , , , , , , | 9 Comments

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 »

Pleasure In Programming

Posted: February 3, 2008 | Author: | Filed under: General | Tags: , , , , , , , | 5 Comments

We’ve long known that a programmer’s productivity depends largely upon how much he enjoys his work environment and the task that he’s been assigned. We know that various things that make the environment nicer assist productivity, for some seemingly ungraspable reason.

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

Beautiful Code

Posted: February 1, 2008 | Author: | Filed under: General | Tags: , , , , , | Leave a comment

In Scientology 0-8: The Book Of Basics, L. Ron Hubbard says:

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

Increasing Complexity Over Time

Posted: January 27, 2008 | Author: | Filed under: General | Tags: , , | 2 Comments

In Dianetics, L. Ron Hubbard mentions:

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

← Older Entries