What's Wrong With Them?

What's wrong with our users? They try to use our software without bothering to learn anything about it and then complain when they run into trouble. They're confused by the terminology we use in the program and try to translate it into something that's more familiar to them. They don't know how to use anything right, and instead do the strangest things to get their work done. For instance, when they need a new field to store some data, instead of asking for it to be added they just start typing special codes into another one of the fields. This inevitably causes data problems down the road. Can't they do anything right?

I don't think users are stupid or difficult. Instead, there's something about their relationship with programmers that makes them seem that way. Look at how programmers act when they're users themselves. How do programmers act when they use the software they need to get their job done? Do they read the manual before doing anything? Do they only use the software in the recommended way? When the software doesn't work quite like they want do they patiently wait for an update or do they hack in a workaround that they know is going to cause problems? We all know the answers to these questions. When programmers are users they act just like users. If you listen to them complain about the software they use you'll notice they even sound like users. There's nothing strange about user's behavior; it's human nature. Everyone treats programs like that. So why do programmers get so worked up about it?

Programmers emotionally identify with the programs they write. To them, the program is their creation, an expression of their own self. To the user, a program is just some piece of junk that's supposed to help them get their work done, if only it would work right. The user doesn't think they're hurting anyone's feelings when they criticize a program, but it's amazing how rejected you feel when someone doesn't like your work. Programmers aren't supposed to show these hurt feelings and that's when the trouble begins.

There's a few different ways to suppress hurt feelings. One is to attack the person who's hurting you. If the users are dumb or overly critical then their judgment doesn't count, so looking at users like that is one way programmers cope with criticism. Realistically, if the system isn't making sense to the users, then it's probably the programmer who didn't understand what the users needed, not vice versa. Instead of accepting the painful truth that they haven't done their job, programmers project that failure onto the user. Programmers trick themselves into believing users have poor judgment, all to not face up to their own poor judgment.

The more common method of escaping from painful feelings is to hide. Most programming is done in complete isolation from the users and their daily work. The majority of programmers never meet anyone that uses their programs, much less actually sit down and watch them work. Yet few people in the business think this is strange or needs to change. No matter how complete requirements are, millions of questions come up while writing the code which need to be answered somehow. Usually you guess. Guessing by it's nature is inaccurate. So the isolation, created to avoid users and their questions, actually make the software worse. The internet, which was supposed to make everyone more connected, has eliminated software installation, so programmers don't have to be physically near users when updating software. Programmers are more isolated than ever and the software suffers.

What needs to happen to fix these problems? Programmers need to identify more with users instead of the programs they write. As long as programmers consider their relationship with users adversarial, they will react to any criticism, feeding their own hostility and isolation. Programmers need to recognize that they have a part in the breakdown in communication with users and strive to fix their part in it. That means taking users and their problems seriously.

Emergency Room Burnout

By nature, you ignore what's familiar to you. Things that happen all the time become background noise to you, something that barely registers. This happens when you learn something as well. When you first learned to drive a car it took a lot of concentration, but now it's probably so second nature you barely notice you're doing it. This frees up your mind to pay attention when something changes drastically, because that's usually the sign of danger, something you need to notice. This instinct works well normally since ordinary things can usually be safely ignored, but it breaks down in certain artificial environments.

In an emergency room, becoming numb to the everyday means becoming numb to emergencies. How can you get excited over a patient when you know another one is just behind them? It doesn't help that many emergencies are anything but. Many people come to the emergency room with trivial complaints, many are there because they can't take care of themselves. These people have to be treated the same as true emergencies, but that just makes it easier to treat everyone callously. Bureaucracy naturally grows around ER medicine because a mistake can be life or death, but the bureaucracy just adds to the numbing effect. And people die. When death becomes ordinary, your attitude toward death becomes very different from most people. To an outsider, this behavior can seem callous or arrogant, but it's really a human instinct perverted by the artificial environment of the emergency room.

Many programming groups are run like emergency rooms. Everything sent in is labeled "rush, stop everything!" After awhile it becomes impossible to be excited about problems. What's the point of rushing to fix something when another bug will be right behind it? Once you become numb to the infinite progression of bugs, it becomes impossible to get excited about users' problems. This leads to a callousness that users find infuriating. Where a user sees a piece of software as a necessity to get their job done, the programmer sees a piece of junk that never worked right and never will. When you walk through an IT department and see people laughing and goofing off when a major outage has occurred, you're seeing the detachment that comes when disaster is everyday. When everything's an emergency, nothing's an emergency.

Many managers try to fix this by upping the threat level. This works for a little while, but like any addiction cycle, programmers quickly become used to the higher dose and return to their numb daze. Raising priorities feels right because what you're trying to do is motivate people, but it doesn't work because the sameness of emergencies is what's causing the problems. Human beings recognize things through contrast, and without that contrast everything blurs together. People also need a mental break from emergencies to prepare themselves for the next one. If they don't get a break as part of their week, then their overloaded mind will shut them down anyway, and will probably not pick the shutdown time based on management priorities.

The solutions for these problems are written in many programming books. Increase usability to minimize user complaints. Test to increase reliability. Rotate personnel off maintenance so they don't get burned out. These techniques have been adequately explained elsewhere. What I want to emphasize here is that human psychology is what makes these techniques necessary. Human beings aren't like machines; they can't do the same thing over and over without it effecting them. People need variety and contrast to properly react to events around them. When emergencies are rare, they get treated like emergencies.

The Bad Tourist

Think of a country, it doesn't matter which one. Somewhere in this country, far away from any cosmopolitan city, is a tourist that hasn't bothered to learn the native language. Red-faced and cursing, he's yelling at the natives in his own language in the mistaken belief that anything can be understood if it's said loud and often enough. Most natives avoid him, looking terrified. If any of his countrymen are unfortunate enough to be near he will corner them, muttering about the ignorance of people who can't learn a language so easy a child of three can speak it. If his anger is deep enough, he will swear that the natives are pretending to not understand just to drive him crazy. His frustration blinds him to his own ignorance, and so prevents him from learning a better way to communicate.

There's another type of tourist as well. This tourist has tried to learn the native language, but his skills are so poor few can understand him. Many talk to him slowly, enunciating each word, just like you'd talk to a baby. Even worse, some natives will mistake his halting sentences for fluency, and will answer the tourist with a burst of incomprehensible speech. But after seeing the dumb, frightened look on the tourist's face, the native reverts to baby talk. This sort of tourist feels humiliated by his treatment and the evidence of his ignorance. He often will change into the first type of tourist by the end of his trip. It's easier to retreat to what you know than go through the pain of learning something new.

Programmers are tourists in the user's world. Programs are written for a specific audience, and the audience has it's own dialect for talking about their work. Oftentimes developers will not bother to learn this new tongue, and instead run around shouting their own language, which sounds like gibberish to users. The programmer assumes users are too stupid to understand, but what users see is a lout who can't be bothered to learn anything about the country he's visiting.

Some developers do try to learn the native language, but don't go far enough. They seize on one or two user terms and use them constantly. This can sound both patronizing and ignorant to users. And when users ask a detailed question the programmer is immediately lost. Often he will try to hide his lack of fluency by pretending to understand, like a foreigner nodding through incomprehension. The pretense fools no one. The users feel frustrated, and the programmer, in embarrassment, retreats to his shell. If translation problems aren't seen as a chance to learn more from each other, the opportunity to improve the users' system is lost.

This isn't all the developers' fault; users do this too. Many users don't bother to learn anything about computers and so have unrealistic expectations about what can be done and how soon. This naiveté leads to frustration with the development process, and to the common belief that programmers are messing up on purpose. These users get trapped in the same situation as the bad tourist: their lack of education creates even more distance between them and the people they're supposed to be working with.

Language barriers create frustrating emotional binds, which make working together hard. But the emotional symptoms are good in a way, since they can be used to diagnose communication problems. Whenever someone takes on the personality of the bad tourist, repeating himself over and over, frightening others away, and swearing the natives are plotting against him, you can be sure that there's a language barrier between him and whoever he's arguing about. This is most useful when diagnosing yourself, because it's harder to see these things when you're trapped in your own emotional storm. When you've spotted a communication problem, remember that the solution is not to say the same thing in different words. What's needed is a willingness to learn something about the other side.

Stop Being Lazy

Like all human beings, programmers are naturally lazy. Sometimes this laziness can be positive, when they build an easier way to do something, or avoid complexity. But laziness usually causes problems. It trades a quick fix today for a long, arduous bug fixing session down the road. Unfortunately, programmer laziness is harder to recognize than other kinds, especially when many programmers cover it up by inventing fake technical reasons for it. Let's look at how programmers can be lazy.

Programmers usually look for a solution that’s simple for them to implement, not something that’s simple for anyone to use. This gets things done quickly which pleases management, but it makes users' lives a misery. This preference for programmer performance over user performance has serious consequences. The whole point of automation is to reduce the workload and increase the productivity of users. If the program is sacrificing users' productivity to programmers' laziness, it's flying in the face of what programming is supposed to be about. What's easy to use should always be more important than what's easy to program.

Programmers grab the first solution they think of, instead of looking for other, better ones. In most cases, the first solution is not the best, so looking further afield is necessary to program well. Getting locked in to a design is another case of saving time at first and paying for it later. With any big decision a few alternatives should be considered before going ahead with one. But never believe that there is a perfect design waiting out there for you. Every design has trade-offs and compromises, most of which you won’t understand until it’s already implemented.

This laziness about selecting alternatives plays out in another way too. When writing something, a programmer makes a huge number of decisions; some right, some wrong. To be a good programmer you need to recognize your bad decisions and rip out the code that implements them. Unfortunately, programmers naturally resist tearing apart something they’ve already written. There’s an element of laziness to it, but it’s more a problem with focus. It’s hard to step back and look dispassionately at what you’ve done and admit you made a mistake. As a result, systems get clogged with all kinds of junk. This not only makes it harder for the maintenance programmers, it can slow down the system.

When the system goes into production, it's too late to clean up. Pulling out the bad code might create more bugs than it fixes, so you'll be discouraged from doing so. As a result, production systems get filled with zombie code – dead code that no one dares touch, so it never gets deleted. The bad ideas in the code eventually percolate up to the interface, making the users miserable. Once the users complain enough, the junk will have to be removed. Wouldn’t you rather fix things before it gets to that point?

Not only should you fix things before the users find out, it’s easier to recognize bad ideas as you write, and easier to remove them while they’re still fresh enough that you understand what you were doing. Young programmers are usually resistant to cleaning up after themselves. Coding anything is such an effort for them that they abandon their mess in frustration and stagger off to the next disaster. But once programmers become confident and experienced enough, they should learn to reread their code and reorganize things that don’t work well. This will actually speed up the coding process because time won’t be wasted programming around junk.

Programmer laziness causes a lot of the problems we see in computing today – kludgey interfaces, inefficient code and poor performance. The solution is no different from what a good writer does; reread code as it's written, try it out, and keep the ultimate goal in mind. The goal of programming is making things easier for users. When that's central to what you're doing, it's easier to make the right programming decisions.

Your Company On The Couch

Suppose you work on a huge, complicated program that has major problems. This monster is central to the business, runs all the time and has far and away more bugs than any other program in production. The amount of time being sucked up just fighting the problems has management thinking it's time for some kind of rewrite, but everyone's afraid of what that would mean.

Look a little closer. Examining what bugs have been logged shows that the vast majority of them are against the part of the code that does data correction. The bad data that's causing the bugs is traced back to an obscure program that never had any bugs logged against it. If this little program is rewritten to stop sending bad data to the monster, most of the problems would go away. So even though the big program had the bugs logged against it, it was the small program that everyone thought was reliable that was causing the problems.

The big program is similar to what family psychotherapy calls the “identified patient”. The identified patient is the member of a family who the family agrees is the problem. The patient is usually the one with symptoms of either depression, neurosis, or others. But although the identified patient seems to be the only family member who isn't functioning well, family therapy sees the family as a system, and so the therapist looks at how the family works together to find out what's causing the identified patient's symptoms. Typically, a therapist gets better results from adjusting the behavior of other family members instead of concentrating on the identified patient. In fact, if the therapist buys into the family's assessment and only tries to address the patient's behavior, the therapist usually becomes part of the problem itself and won't be able to help the family function better. This is why it's important for a therapist to remain objective enough to look beyond the symptomatic family member to the full system of the family.

A company can be thought of as a family, made of departments and the software that serves them. Like families, some companies are close, some are impersonal, some seem well-adjusted and some seem dysfunctional. Just like in families, the dysfunction is usually concentrated in one department or system. But just because the breakdown appears in one place doesn't mean that the rest of the system around it isn't contributing in some way. In fact, like in the case of families, efforts to fix the dysfunctional part without looking at the rest of the system will likely fail.

Let's look at another example and try to see it as family therapist. Instead of concentrating on the specific problem, look farther afield at how the system is working or not working. At company X, some program keeps getting changed over and over. Careful examination discovers that one section is being changed back and forth at the request of two different departments. The departments are having the code changed because they have different ideas about how the program should work.

So what's the problem? Is it:

1. The two departments should communicate with each other.
2. The documentation should explain precisely what the program should do.
3. New development should have discovered and resolved the contradictory desires when the program was written.
4. Maintenance should have noticed the problem and mentioned it to someone.
5. Management should have built a process to prevent such problems or at least detect them.

Of course each one of these suggestions can be pursued as its own problem with its own set of possible causes. You can look at this as a tree structure with the original problem as the root. In real life you don't need to search the tree to any great depth, but you have to at least look beyond the root. Probably all of these issues are contributing to the original problem, but some are worse than others. A few inquiries will tell you which of these problems have priority.

Although the examples above are at a higher level, this all applies to the nuts and bolts of programming as well. It's easy to get caught up in thinking that one part of your program is causing problems and ignoring other possibilities. But this tunnel vision blinds you to other possibilities around you and many times causes you to fail.  Imagination and objectivity are needed to look past what's right in front of you, and think about what other solutions are possible.

Tripping Over Your Own Feet

At the office everyone jokes about multi-tasking, in the sort of unfunny way one jokes about pain to be endured. But multi-tasking is a myth. There's been research showing it doesn't work but you don't need to look at a study to know that. Just watch someone try to walk and push buttons on their cell phone at the same time. Not only do they get in other people's way, walk into things and generally act like they're lost; it's also obvious they're having a hard time operating their cell phone. Multi-tasking means doing every job worse than if you did each one singly.

But there's something deeper going on here too. The most interesting thing about distraction is how nobody's really aware of their own. Human attention is positive; it only notices what it's looking at. When you don't have enough attention for your current tasks, you certainly don't have enough attention to observe your own functioning. So although it's very easy to see that the guy walking and pushing buttons is distracted, he's completely unaware of it. If he realizes he's having trouble, he just thinks that what he's doing is hard or confusing. And because of this he never thinks to sit down before clicking away on his cell. The first thing distraction removes is your consciousness of being distracted.

But it gets worse. When you're having trouble doing something, the natural instinct is to give it more attention. But when your difficulties are caused by divided attention, paying more attention just means you have less attention to give to your own functioning or upcoming obstacles. Distraction feeds on itself and also shuts off the one thing that can bring you out of distraction: self-awareness. When you do a lousy job on a few things you have to work harder to get them done and catch up on everything else too. Pretty soon you're working so hard you can't do anything right. At this point most people think they're burnt out and need a vacation. What they're really doing is breaking away from all the mental noise in the office that's keeping them distracted.

See, removing distractions doesn't just mean only doing one thing at a time. It also means giving yourself enough time to finish something before you start what's next. That time includes the seemingly useless time needed to decompress. A manager that spends all day in meetings without a break is just as distracted as a programmer working on three projects at once. His full attention isn't on any one thing, so nothing gets done particularly well. But like with any distraction, although it's obvious to all his employees, the boss is unaware of his underfunctioning.

One of the important cures for distraction is to become self-aware enough to recognize it in yourself. Look for the symptoms. Confusion, impatience, or a feeling of pressure or buzzing in your head are all typical. Symptoms can also be unique to yourself, and only you will be able to diagnose them. So you need to pay enough attention to your own functioning to notice when it drops. When you do notice it, you will know it's time to go take a walk, delegate some problem, or take a day off. Reducing your mental load, instead of working harder, is what keeps you sure-footed and in the right direction.

Grabbing the Dog Toy

If you've ever played with a dog you know about this. The dog brings you a ball to throw and sets it at your feet. When you reach down to grab it, the dog takes it back. If you try to take the toy from the dog, he'll refuse to let go. The harder you try to get the toy, the deeper he sinks his teeth into it. Don't think your point of view is superior to the dog's; you're as emotionally connected to the ball as he is. And as long as the relationship between the two of you is defined by your desire for the ball, you'll get nowhere. The only way you can get the toy is ignore it, wait for the dog to leave it alone and then snatch it away when he's distracted. Interestingly, once you have the toy, the dog changes from angrily defending its property to happily waiting for you to throw the ball.

Human beings are social creatures like dogs, and we aren't that different from them. At certain times we revert to adversarial relationships, even if it's against our own interest. Any attempt to address the problem directly seems to cause everyone to dig in their heels even more, making things worse. Breaking out of this bond requires distraction, either by changing the subject or getting away from the problem long enough to cool down.

Fights with customers over whether a change is a bug or an enhancement are notorious for how much emotion they raise and how impossible it is to come to an agreement. Even though classifying something as an enhancement means more time will be spent getting it right, customers feel like their change is being snatched away from them to some far off future they'll never see. Distract the customer away from their bug definition by defining the process instead. A change can either be made quickly with minimal testing or can go through a whole design-code-test-document cycle. These terms are easier to swallow because they don't make the customer feel like their change is being taken away. Throw that ball as hard as you can and the customer will run after it.

But customers aren't the only ones that can't let go of dog toys; it's a universal affliction. It's easy to become possessive about a piece of code, a build method or an operating system and feel defensive when someone criticizes them. Although this behavior is easy to recognize in others, it's hard to see when you're the one with your teeth sunk into something you should let go. Being too attached to anything, from a variable name to a business process, makes it that much harder to drop when necessary. You should be able to step back from anything enough to judge whether it's time to give it up.

This is done by being alone. Defensive aggression is a perversion of social behavior so you have to be antisocial to break out of it. Our business culture encourages endless meetings to talk out problems but sometimes you need to be alone with your own thoughts to figure something out. The social network feeds your need for defense from perceived attacks, so leaving it allows you to look at something objectively without thinking of it as your property.

This doesn't necessarily mean being physically alone. Everyone knows you can be alone in your thoughts even if someone is present. But most don't realize that even if no one is around, you could still not be alone enough to think. If, in your head, you're rehashing an argument with someone you aren't really alone. You're still acting out a defensive social posture against the character in your mind, who strangely, knows how to push your buttons better than any real person does. You need to banish this person, either by ignoring them or waiting until they get tired and leave you alone. Then you'll be alone enough to think about things without getting defensive. At this point you can relax your jaws, let the ball fall on the grass, and think of something else.

Code Is Meaningless

Computer languages are great for describing how to do something, but they can't explain why. Why add two to the personCounter? Why is statusField set to the empty string when counterField is null? Questions like these don't get answered by code. Code is very good at answering what and how questions, but why questions are completely impossible for it. So documentation was invented to provide a way to explain why something is the way it is. Unfortunately, few use it this way.

Instead, for programmers we have what's called echo documentation:

/**

* Gets a value.

*

* @return value the value returned

*/

public int getValue() {

   return this.value;

}

Many programmers will document their code by simply repeating what's there. There's no indication of what anything is used for, or why it was designed the way it was. Instead of explaining anything they echo the code. This isn't really documentation.

For users, we have a numbered list of exact instructions, in other words, a program:

1. Click the button labeled “Excute”.
2. In the popup window that appears, select the radio button labeled “Process Records”.
3. Click the OK button.
4. Now select “File/Open...” from the menu.

This style is marginally useful, but it still doesn't do what documentation is supposed to do: answer the questions the interface itself can't answer. It doesn't give the user a chance to do anything more than mindlessly follow directions. This is great for computers but human beings need something different.

Your brain needs information to be balanced between how and why just as your body needs nutritionally balanced food. Eating unhealthy food can leave you with the uncomfortable sensation of being full and hungry at the same time. This same thing happens to your brain when confronted with mounds of data and little explanation. You feel dizzy from the sheer volume of information, but are still confused as to exactly what's going on. And just like junk food that passes through your system without contributing much, most data bereft of reasons for its existence will be quickly forgotten. Documentation that's heavy on information but light on explanation creates more confusion than it prevents.

Why is why necessary? Answering why is so important because it helps human beings store information. To understand something, the human mind needs to create a mental model of it to hang details on. Without the mental model, the mass of details overwhelms the brain's capacity to store them, and the brain forgets most of what was said. People feel lost and confused when this happens, because they have no mental map to orient themselves on. But once they have that mental model to organize things around, human beings can remember an enormous amount of information. Although few people can memorize more than ten phone numbers, most people know more than ten thousand words. Meaning creates the conditions necessary for understanding.

Think of the mental model as a data structure that someone builds in their brain. You don't want to shove information into someone, overflowing their buffer, causing them to forget most of what you tell them. Instead you need to start out telling people how to construct the data structure they need to understand your system. Then you can add details, letting the user know where in their mental model the details fit. This way the human brain can store a lot more information, because it has someplace to put it. When someone has a mental model of something, they say they “understand” it, meaning if you gave them more information they would have somewhere to store it.

To see how different something looks once you have a mental model for it already built, look at the following interface:

Afsefioj:	adiefdif
Jheisp:
Diep:
Bivi:

It's just some fields that seem to have nothing to do with each other. Nothing really suggests what should be entered in them or how they would be used. Now look at the same interface labeled correctly:

Protocol:	httphttps
Server:
Port:
Path:

Now, because you already know what a URL is, the fields make sense. You see how they relate to each other and can think of some possible values. The structure in your brain that stores what a URL is helps you understand this interface. Without that information in your brain, the interface wouldn't help you understand what the program is about.

This is radically different from the way programs work. Computer programs always have the internal data structure already decided on, and coded into the program. Human beings, on the other hand, have no preset structure, so the first thing you must do is give them the structure that the rest of the data will be a part of.

Documentation should be about creating mental models. The docs don't even have to be complete; once a human being has a mental model, they can discover a lot of information on their own without instructions. But without the model a person is lost and can't do much more than mindlessly follow directions.