In Dianetics: The Modern Science Of Mental Health, L. Ron Hubbard says:
It is not untrue that where one finds the greatest controversy, there he will also find the least comprehension. And where the facts are least precise, there one can also find the greatest arguments.
There are some areas of computing that are very difficult to comprehend. There are also areas where the facts are very imprecise, or where no real facts are known (there are just guesses or theories, instead).
In these areas, programmers can get into endless technical debates that seem to get nowhere.
The subject of “security” is often like this. Developers can get into extremely long technical debates about how to implement security features in their programs, how to fix security issues, and so on. But, um, security from what? Security that allows the user to do what? How important is security? What level of security is important? What is the basic, fundamental point of computer security? What do we even mean when we say “computer security”? If I say my program is “secure”, what does that mean?
Can you see that there might be some things there that are hard to comprehend, or that there might be some imprecise facts in that field?
The subject of user interface design is also like this. Developers can get into some knock-down, drag-out fights about user interfaces, probably because they don’t understand them, and because the field is full of imprecise facts. I personally leave most UI work to the UI engineers, and stay out of it. 🙂 I let the people who do comprehend these things do their job, and I don’t encourage debates in areas that are poorly understood.
When I don’t understand something, or when the facts aren’t precise enough, I think there’s nothing wrong with saying, “I don’t understand this!” or “We need more data!” And that’s the end of the conversation. There really shouldn’t be any more debate after that, because it’s going to get nowhere!
Whenever a technical debate goes on and on without resolution, I say, “Okay, obviously something is unknown here. What more could we find out about this?”
There’s nothing wrong with debating the pros and cons of technical issues. But when it becomes really controversial or people become strongly argumentative, that’s when I start applying the quote above from Dianetics.
As an exercise, you can see for yourself if this applies. Look at an area in computing where there’s a lot of controversy (such as operating systems, programming languages, security, etc.), and check: Are there some imprecise facts, or is there some missing comprehension in that field?
In Dianetics: The Modern Science of Mental Health, L. Ron Hubbard discusses a principle called the Introduction of an Arbitrary:
An aribtrary structure is one in which one error has been observed and an effort has been made to correct it by introducing another error. In progressive complexity, new errors must be introduced to nullify the evil effects of old errors.
How many times have you seen this happen with a software project? It’s poorly designed in the first place, and then somebody discovers an error. Instead of fixing the design, they tack on some “hack” to fix the error. In other words, just like Ron says, they keep introducing new errors.
It’s long been known that this is a bad idea, but the new idea here is to look at this as a process of introducing errors. Just because some code “fixes a bug” doesn’t mean that it’s not an error to write code that way. You are actually introducing new errors into your program every time you “hack” in a fix instead of fixing the real root cause of a problem.
I think most professional developers have long felt uneasy with “hacking” in a fix, but perhaps didn’t quite have anything to back them up when they protested and said, “I just want to fix it the right way!” However, if we look at “hacks” as errors, then it becomes easier to see why the “right way” is the right way.
So in the future, when you’re fixing an error, don’t introduce new errors to fix it. Do things the “right way.” 🙂
In Scientology, one of the most important ideas is called ARC, which stands for Affinity, Reality, and Communication.
I was thinking the other day about an interesting way that this applies to computing.
The first thing you have to realize is that as a programmer, your user interface is a Communication to the user. Over a very long distance, you are actually communicating something to the user. You happen to be communicating a window with some buttons and funny words in it, actually.
Now, it’s always mystified me why users like pretty interfaces that are impossible to use. That is, why does it sometimes seem like aesthetics is more important than usability? Well, one important thing to consider here is that the user will have to have some Affinity, or liking, for your user interface. People tend to have more affinity for pretty things. So the more “likable” your user interface is, the more effective your program is going to be. Of course, I think “likable” also includes usable, since I personally really dislike user interfaces that are hard to use. That is, my affinity for them is low. So, both “pretty” and “usable” are important to affinity, for user interfaces.
You as a programmer should also have some affinity for the user–generally if you’re thinking, “I’d like to help this nice guy be able to use my program better,” that’s a lot better than, “All my users are stupid and I don’t care if they can use this thing at all.”
The final aspect of the triangle is Reality, which we usually think of as agreement. Does your user know what that weird little icon means? Is there actually reality (agreement) between you and the user? There are lots of important pre-arranged agreements with computers that are important to remember. For example, “When I click the X button, the window will close.” That’s pretty much true on all operating systems (even Linux, which I’m using now). If I clicked the X button and I got a screen full of dancing pigs, I’d probably be annoyed (though slightly amused), because “dancing pigs” wasn’t really my reality, there.
All together, ARC adds up to Understanding. So, if users are having a hard time understanding your program, check which component you’re missing! Are you failing to communicate something? Is the affinity between you and the user too low? Or is there some missing reality (or some reality that you enforced upon them without their permission)?
There’s lots of ways to use this concept of ARC in user interface design, and lots of different ways it could go wrong. The items in the blog above are just examples, to sort of get your mind rolling on it.