10.9 Psychological Akido

Being an architect is a tough job. It can be particularly challenging to the psychological health of the architect. Staying positive and happy can be difficult, especially when shouldering the weight of the whole world. And bad things happen all the time. It can be quite frustrating at times. Most adults experience frustration often; statistically, a typical adult gets angry about ten times every day. That's normal psychology.

The common man, inexperienced in psychological warfare, is constantly trying to get out of trouble. As experienced warriors, architects embrace trouble as much as they embrace success. Good and bad things happen. Most of the events are of small consequence. And many events are out of the control of the software architect. To be happy in a world of trouble, people must learn to let things go that cannot be controlled and to contribute to the success of those events that can be influenced.

To acquire the ability to endure bad events and remain happy, a philosophy of personal expectation management is helpful. Software architects try to create success on software projects and try to help their peers and colleagues achieve career and personal success; however, in their personal expectation management, they should expect nothing-no change in outcome, regarding their involvement. Like medical doctors, they should try to do no harm. But there are times when good work leads to bad outcomes, too. It's the luck of the draw. Every day and every decision is a gamble. When nothing happens, great! It was to be expected. When good things happen, great! It's a pleasant surprise. When bad things happen, there is often a much greater opportunity to be exploited. All people would be much better off if they looked for it and attempted to bounce forward, instead of being discouraged.

Software architects learn the most from their mistakes and the least from their successes. They do not, however, seek to fail. With an attitude of personal expectation management, they don't expect their strategies and patterns to work. So they give it their best effort, acting as if it won't work unless the input is perfect (in a time-bounded sense, of course). For example, suppose that a software design pattern is being applied to an architecture. If the architect makes a half-hearted effort to apply the pattern, it's very unlikely to generate benefits. Developers will easily ignore it or misuse it so that the benefits evaporate. If the pattern is applied with a reasonable effort, reasonable documentation, and so forth, they assume that good things will happen and that, with luck, the pattern will generate benefits. Developers might understand exactly what is meant, and might even add value to the pattern application. This is wishful thinking in practice. Finally, suppose that an architect decides to use the pattern, assumes that it's likely to go wrong, and applies it with exceptional care and due diligence, documenting and communicating clearly his or her intentions to the developers. Even though the architect expects nothing, he or she has given the pattern the best chance to perform its function. If nothing good happens, so be it. If it works, that's great, and a very pleasant surprise.

In Psychological Akido, these philosophies are applied in terms of a process of learning. Both good and bad things are expected to happen as a result of the architectural work. The goal is to understand "how things happen." MBAs learn that good things happen when the "action lever" is pulled. An action lever is anything that can be done to effect change. Unfortunately, this is a world of confusion, of increasing change and information overload. Seeing the action lever is difficult and often requires experience and expertise. That's why companies hire expert consultants who know where the action lever is. An architect plays this role as well, within the scope of technology and system building.

When good things happen, an action lever has been uncovered, perhaps by accident. The cause may not be immediately obvious. Consequently, the architect tries to apply the same techniques again in a systematic, experimental way, to refine the knowledge of the action lever. When bad things happen, even more information is available. The architect has found one or more destruct buttons, which must be avoided on future trials. As experience progresses, the architect learns to avoid the destruct buttons and to pull the action levers, becoming more effective.

It is interesting to note that the process of learning to use a computer involves these principles directly. In one dramatic experience, the authors once took a programming class for a new operating system, in beta test. The software had many defects, as all commercial operating systems do, but these defects were much more prevalent than most of the class had ever encountered (in a near-production release), all of us being experienced software engineers. Because we had not learned the destruct buttons of this new software, everybody experienced frequent crashes, requiring reboot. About 30 reboots were needed on the first day alone, as we attempted to perform simple tasks. The situation is similar to when the authors put noncomputer users in front of a demonstration, and the new users broke the software within the first few keystrokes-a well-known phenomenon. In the rebooting laboratory, the authors quickly learned to "do this and this in a specific order" and "not ever do that," plus remove an erroneous file or two after rebooting. Overnight, the software was seen as being hopelessly buggy. By the second day, all students had cut their rebooting needs in half, and sophisticated programming tasks were being performed. By the end of the week, everyone was able to perform extremely sophisticated programming tasks, with virtually no rebooting required, except when the individual chose to reboot. The authors had learned the action levers and the destruct buttons. Most surprisingly, they didn't have to think about it; they did it naturally, as they had internalized this knowledge about how the system was to be used. On reflection, this experience is common to people who use computers. This was just a dramatic example of experienced software engineers repeating the process for new software.

Psychological Akido is much the same, but instead of learning to control a machine, users learn to survive the psychological warfare that is life. The life stresses of software architects are significant. They use Psychological Akido to help cope with life and to learn to perform better and better. Psychological Akido is a quality control process for psychological warfare.