RI-AI

RI-AI

What's in a Name?

In its present day context, Riai (pronounced ree-eye) means Principle of Harmony. The concept of Riai was in practice in ancient fuedal Japan and became one of the top goals of the sword fighting Samurai during the shogunate of Tokugawa Ieyasu. The Tokugawa dynasty lasted from 1603 to 1867 and was the most formal and rigid time for the Samurai in both etiquette and code of conduct. The Samurai of this time endeavored to combine the principles of Sen, Suki, Kiai, Kamae, Zanshin and Maai. When all these principles were in harmony with each other and honed to the highest degree, the Samurai was said to be in a state of Riai.

What is ri-ai? It is the Japanese word to describe when the warrior has the five core disciplines working together in the correct proportion. The five disciplines are kamae, zanshin, sen, ma-ai, and kiai. All of these have their equivelants in software engineering, and help us to become fearless in the sight of complex software.

My desire is to provide a unified view of approaching software from a martial arts perspective. While the words I am using are Japanese (in romanji form), elements of these concepts are in all forms of martial arts in some way. As any martial arts practitioner knows, there are more than one discipline used to improve your abilities. If you only focus on one discipline then your training is incomplete. Most developer's tend to learn while they are developing an application, so it is like trying to learn martial arts only by sparring. You miss so much, and your skill is marginal at best.

The five disciplines that make up ri-ai are kamae, zanshin, sen, ma-ai, and kiai. Kamae are the combative engagement postures, otherwise known as forms. Zanshin is essentially awareness, although its full meaning is to deny the existence of weaknesses (suki). Sen is timing, or the selection of the correct instant to launch your attack against the enemy. Ma-ai is the combative engagement distance, or how far you are from your problem. Kiai is the unity of mind and body--in martial arts this is accomplished through breath control and the kia. Ri-ai is the right proportion of each element and the blending of these major elements of technique in support of a genuinely meaningful combative action sequence. The definitions of these terms were taken from "Japanese Swordmanship: Technique and Practice" by Gordon Warner and Donn F. Draeger.

Kamae: Practicing Your Forms

How often do you try out new development patterns, or work on ones you already know? Probably only when you attempt to use them in your software. Agile processes preach a concept called "Do the simplest thing that will work". However, how do you know what is the simplest thing? How do you know what will work? Sure you have some test cases to prove what you are trying to do, but more often than not it takes solving a problem more than once before you really arrive at the simplest thing.

It helps to know what patterns, or techniques, are in your arsenal. Can you perform a two fingered throw, or are you limited to only reverse punches? How about knowing which techniques compliment each other? These types of things require experience to learn. The only way to acquire experience is to solve a basic problem. In order to be more useful, these basic problems should be small enough to implement quickly, but rooted in issues that are common to most programming tasks. Start by defining the problem, possibly using something from the set provided by PragDave's Code Kata. Next solve that problem in different ways. You heard about some cool new pattern that you are curious about? This is the perfect time to try it out.

Take a step back and contemplate what you have done. Yes all this code is throwaway in the sense that it is not going to be delivered to a customer, but it is indespensible for the knowledge that you have gained. Talk to a more experienced developer to get some comments. This is like taking critique from your sensei. Be humble and openmided. What did you gain, and what did you sacrifice? If your solution was not the best for the problem at hand, how would you improve it?

Using the kata will help you learn new techniques and new languages. You will learn how these languages will help you, and how they might hinder you. In the end, the only code that is incorrect is code that does not meet the requirements. If you cannot pass the tests, you are not ready for more advanced kata.

Zanshin: Increasing Your Awareness

I blogged about this before, but now I am going to expound a little more. To increase your zanshin you have to know your enemy, his vulnerabilities, and your vulnerabilities. How does your enemy like to attack, where would he be more likely to attack? When you perform your kata where do you see your weaknesses exposed?

As a developer, we have tools to help us increase our zanshin, and to deny the existance of weaknesses. Some of these tools include Test Driven Development (TDD), as well as system testing and integration testing. These help identify the areas where we expect problems, as well as the areas we know we must ensure are working properly. Using TDD, we declare our requirements in the form of tests. If the tests fail, it idesntifies a weakness that we must repair. We test the test by making it fail before we make it pass.

Tests alone help increase our zanshin about a particular application or library, but not in the general programming sense. If there is a problem that is not covered by the tests we must be able to identify it quickly. This requires broader knowlege both about the problem domain and about the system the application is running on. While you don't have to know exactly how the thread scheduler works, you have to know enough that they are unpredictable at best. It helps to know what tools are available to help tame them.

Also note that as you improve your kamae, it feeds your zanshin because you learn more both about yourself and your abilities and about your weapons to remove those weaknesses.

Sen: Knowing When to Act

Sen is knowing the precise moment to launch your attack. We've all seen the old martial arts movies where two great masters stare at each other motionless before the final battle. They are finding the right moment for them to act. Too many developers lack patience, and so they act too soon. They either launch into minutia without a good concept of the overall problem to be solved, or they start working on infrastructure without working on the core problem at all. You should not act when you don't know what to act upon.

Many people confuse continuous design with "no design up front". A martial artist studies his enemy, and can intuitively know reasonably well what targets are open and what targets he can make open. The true martial artist will not act on offense until he has decided on the set of techniques and targets he wants to use. Many times these are not conscious decisions, but intuitive ones made based on past experience and the combination of kamae and zanshin. Contrary to myth, the martial artist does not visualize the entire battle before action. Noone is that omniscient.

Using the same process for our development, continuous design provides a natural way to keep the system as simple as possible, while still allowing you to start your attack in a planned manner. More often than not, the martial artist must revise his planned set of actions as he sees his enemy changing their tactics. The developer must be free to have the same agility. It might be that what they started on thinking was the best approach uncovered another area that required attention. Instead of blindly going after the next planned step, the developer must be able to adapt to handle that uncovered area.

Every action that a developer warrior makes has purpose. You should wait for the correct moment before you act.

Ma-ai: How Close Do You Need to Be?

In combat, it is easy to understand ma-ai because you can see how close you are to your foe. Most swordsman are used to a distance where one step will enable them to deliver a lethal blow. However, at times you may find yourself entangled in hand to hand combat at very close range, or you may be much farther in which case a different weapon should be used.

In development, combative distance should be viewed in how close to the problem should you be before you act. Are you looking at the "big picture" or a specific detail. The techniques available to you differ based on how close you are to the problem. You have to know your enemy. If your enemy is more skilled up close (in other words, the detailed code is convoluted) than you are, you might want to fight from farther back. One way of doing this is to re-implement the code to do whatever the larger contract requires. If the enemy is vulnerable up close (the error is obvious), then go right in and attack it immediately. Only experience is the best teacher for helping to establish the proper distance from the problem to attack it efficiently.

This is where kamae helps you learn the best ma-ai. By practicing with small focused issues you can learn what distance you operate best at. It can also help you to learn to think at different levels of abstraction (i.e. this is the different distances from the problem). Learn to cultivate your weak areas, a strong warrior is not satisfied knowing he is weak in an area, he must overcome that weakness.

Kiai: Mind and Body as One

Kiai, acting in unison with mind and body may seem like a stretch for this analogy, but it really isn't. In martial arts, we use a "kia" (you know, that really loud yell) when we perform the finishing move. It is with confidence and commitment that we make that move. You can tell a lot about the confidence in the technique a warrior has by the kia. But, kiai is more than just the kia. It is done through breath control--knowing when to inhale and when to exhale.

A developer's main tool is his mind. The mind can remain focused for only so long before it becomes weary. The developer must learn his limitations so that when they work their mind does too. Learn when you need to take a break, get a drink of cofee, get up and take a walk. Cleanse your mind so that it can remain fresh. A fight is punctuated with quick breaths, so too should your work day. A quick walk to the water cooler, a short chat with a co-worker, etc. can be a very effective tool to let your mind relax and refocus throughout the day.

The key symptom of someone who does not practice good kiai is burnout. There are ways to prevent and overcome burnout. One of the most important being that be where you are when you are there. In other words, don't think about the really hard problem at work when it is time to play volleyball. Don't fret about the testing department finding really ugly bugs on your cookout. When you are at work, be at work. When you are at play, be at play. When you are at rest... be at rest.

Ri-ai: Putting it All Together

Balancing practice, distance, action, breathing, and awareness is not as difficult and insurmountable as it seems. Some see this unity as a spiritual awakening, but I see it as simply a way to calm yourself and be more efficient. It all starts with kamae. Learn the mechanics first. Then focus on ma-ai, so that you know where your techniques work best. All the time, build up your zanshin, your testing skills and your knowlege of the problem domain. Start incorporating kiai so that you don't get burned out. Eventually the kiai becomes second-nature and you don't have to think about it. Sen will come, that knowlege of when to strike, the brainstorm that breaks the fog in your mind will come naturally. Don't overthink it, or you will miss it.

Don't make it spooky, just start incorporating these in your everyday life. The Zen philosophy has a concept of not having a wasted moment. Be fully in the moment. I can't claim to be an expert on Zen, and not being buddhist there is only so much I can agree with the philosophy. Nevertheless, there are principles that you can glean from. Act without apology, and don't fear the independant testors.

Etiquette: The Forgotten Factor

All too often we run into brash people who seem to know how to bully there way through a conversation. Do not fear these people, but don't be one of them. There is a way of speaking your mind without shrapnel to tear people apart in the process. We have to work with others, so it is important to realize that we all deserve a certain amount of respect simply for the profession and discipline we have (or are pursuing).

Even two samurai who are mortal enemies can have an afternoon together sipping sake and telling jokes. I say this because I have run accross some people who pride themselves on "being tough to convince, but it's possible if you have a good argument." The problem is that it places their oppinion of a good argument as the never attainable goal. Their pride has pushed their oppinion to the level of fact, whether it can be backed or not. This type of person is rarely ever open to new ideas or ways of thinking.

Extend people the courtesy of listening to another's argument. Absorb it, perhaps there is something there to learn from. Even children have moments of brilliance. Only after you have heard the full argument and gotten your clarification should you start to gently expose the weaknesses in the approach. Bear in mind that there is no silver bullet. Each technique has its strengths and weaknesses. Perhaps the proposed solution is perfect for your problem, perhaps it isn't. Don't dismiss the person or his argument until you know for sure.

Common courtesy is an uncommon thing. Nothing truer can be said about communication in the digital era. Many people hide behind a certain level of anonymity so that they can spout off their ignorance. Even so, the balance is to make sure it is ignorance before you respond. A couple well placed questions can determine that. Even when you are correcting someone's ignorance you should use "velvet bricks". They get the message accross clearly, but they don't tear a person to shreds in the process.

Programming : Improving your Developer Ri-Ai
Posted by bloritsch on 2004/5/21 9:42:58 (2197 reads)

Post został pochwalony 0 razy

Ostatnio zmieniony przez voivod dnia Czw 14:20, 09 Lip 2009, w całości zmieniany 5 razy