22. In my school, no consideration is given to anything unreasonable; the heart of the matter is to use the power of the knowledge of martial arts to gain victory any way you can...
Applying Musashi to Software Development
If you read this after you have read the book, you will recognize that I share three things with Musashi. The last I keep different.
Appropriate tool, appropriate technique. Know your tools, know what you need at the moment, and you will know how to get value out of the tools at your disposal, even if they aren't perfect.
Various tools can be brought to bear to cover the needs of the project, even if they were not originally constructed for software development. When I am given a CASE tool to use, I exclude from use all those capabilities of the tool that do not lend value to the project at hand. While on the one hand this is an underutitlization of an expensive tool, my goal is not to use a tool to its maximum, it is to deliver software.
On a different project, we may make it a prime strategy on the project to generate code from the CASE tool. In this case, getting and tuning that generated code becomes a prime target of project development. We extend the tool, as we need, so that it performs the job it is supposed to.
Withoug getting overly attached to any one tool or technique, know your favorites for key tasks, and learn to adapt to whatever is available.
Direct solution. In sword fighting, if you can simply cut off your opponents arms with a single blow, do it. In software terms, see if you can just "do it and go home." Avoid waste. If you have to feint, block, perry, and so on, understand that you are doing so because there is no alternative, and do just enough of that to win. Avoid flambouyant showmanship, as it does not help deliver the system.
In software development, look for simple solutions to process problems as you look for simple solutions to technical problems. Recall the one-sentence summary of Crystal Clear: "Put the people in a room with lots of (printing) whiteboards, give them access to user experts, and have them deliver running tested software every two months." If you can do that, just do that.
Reflection and skill development. Continue to develop your skill, take time to reflect at regular intervals.
Microtouch Intervention
Musashi was in the business of killing or getting killed. Here I part company with him, personally and professionally. I am in the business of helping teams of people deliver software. There is a dramatic difference.
I like to cut quickly to the heart of the problem, but keep the people fully intact. Arm-chopping is not an effective intevention strategy.
I am after the smallest possible changes to the people on a project that accomplishes the job: microtouch intervention. (Actually, I don't think Musashi would disagree with this, if he were in this business.)
Microtouch intervention is based on two ideas: that with better understanding, smaller interventions are required, and that many microscopic changes can produce a very large effect in unison.
Doctors used to amputate; now they issue antibiotics. Early syphilis patients died; a century ago they went through near-deadly arsenic treatments; now they are given antibiotics. Early antibiotics were broad-spectrum bacteria killers; nowadays the antibiotics are targeted to the specific bacteria they are to kill.
Early computers were made with large vacuum tubes; then they were made with transistors; now they are made with mere thousands of atoms, recently even just single atoms.
Less energy is needed to effect a needed change the better we understand what we are doing. When we get it right, all it takes is moving molecules or atoms a small distance, and the consequences will ripple out to produce the macro-effect we are interested in.
So it is with adjusting software development. We are still in the amputation stage. As we better understand the underlying forces, we can make smaller and smaller changes to a improve a situation. Knowing that requesting changes to personal habits are large requests, I look at changing team seating,or changing a few job assignments, and let the communication nature of humans carry out much larger changes. This is the first half of microtouch intervention.
The other half of microtouch intervention is noting that many minute changes can add together powerfully. I find it remarkable that aligning many, microscopic magnetic domains produces a strong magnet.
In the same way (shown graphically in Figure 5-18), suppose that each person on the development team is working to their own value system, pursuing whatever goals happen to hit them each day. They will sometimes, almost randomly, help each other, or thwart each other. Suppose, now, that each person is asked to make a miniscule change, one that they find acceptably small. It is possible to arrange all the people's small changes to be oriented in the same direction, so that they thwart each other less, help each other more. With almost no energy change, the project team achieves a power all out of proportion to the changes made.
As with any technique, microtouch intervention has its limits. Sometimes, the correct answer is not to continue with microtouch intervention, but to replace the entire project structure with a new one. This happened once when we saw that a 30-person, colocated team could deliver the same as the failing 300-person multi-national team.
The art, of course, is knowing when to rebuild the project, and when microtouch intervention will work. Makes me wonder how Musashi would express that.