Monday, January 31, 2011

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.

Tuesday, January 18, 2011

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.

Tuesday, January 4, 2011

Writing Is Key

There are two things you need to learn before you learn programming. One is typing. If you can’t type, you’re all but illiterate today. Hunt and peck typists refuse to type anything out because it’s so hard for them, so they don’t write documentation, explain problems to users or management, or communicate their design to other programmers. If you can’t type, you’re stuck with face to face communication and cut and paste programming. You’re like a primitive caveman who has to rely on his memory for everything and if he can’t remember it, it doesn’t exist. Typing is necessary.

The second and more important thing you have to learn is how to write. You may think you can’t write. You may have fallen for that left-brain/right-brain hogwash and believe it’s impossible for you to learn to write. You may believe it takes an innate talent to write. You may think that you were cheated out of an education in high school and it’s too late to fix that. You may believe writing is a waste of time. You’d be wrong on all counts.

There’s plenty of community colleges that have writing courses. Such courses are on writing alone and don’t teach to a test, so you aren’t distracted by other junk and can concentrate on learning. You get to choose what to write about, which makes it easier to come up with ideas. You can take the course pass/fail, so you aren’t distracted by the nonsense of grades. Instead, you pay your money and learn a skill. You don’t need to become a great writer; I’m only a passable writer myself. You do need to understand writing enough to be able to express yourself to others. You need to rise above the average illiteracy of today; the clumsy wording and meaningless corporate-speak that is most writing you see at work.

Okay, so you can learn to write; but why would you bother? There’s a million reasons. When you have a problem that’s similar to something that happened six months ago, it’d be useful to have something written down about your earlier solution. When you’re looking at a program you wrote two years ago, it’d be useful to have the code documented, so you can quickly figure out how it works. When you need to add a couple of fixes the users asked for in the last meeting, it’d help to have that list written down, with a clear explanation of what the users wanted. Any program you write must have user documentation, and it’d be easier to hand your doc writer a decent list and description of features instead of spending hours rambling about what you remember coding. When you get a nasty email from the boss, it’d be useful to be able to explain yourself clearly so you don’t get in trouble.

You may be thinking that most of these examples are about things that are no more than three sentences long, so you don’t really need to learn to write. But despite the fact that children are graded and writers are paid by the word, writing isn’t about volume. The skill of writing consists of organizing your thoughts so you can convey them precisely. Even a one sentence description of a function can be improved by someone who knows how to write. And the act of writing, of wrestling with how to say something clearly, will clarify in your mind what you’re trying to do. Writing helps you understand what you need to do even before you start coding.

These skills carry over in another way too. A good writer will take a group of sentences, cut out the unnecessary, clarify the unclear, and rearrange everything until it flows properly. This should sound familiar because this is exactly what a good programmer does when coding. Writing is design. When you write you are exercising the same mental muscles you use when you design and implement a program. So improving your writing skills will not only help you communicate with your boss, your users, and your colleagues; it will also help develop the skills you need when you’re sitting at your desk pounding out code. Writing skills are fundamental to what you do as a programmer.