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.