I just added a new post of the Mentat User Interface design philosophy on the Brain Murmurs blog.
In other news, I just started learning the Fu style Liang Yi form from Andy Dale. This is a great, difficult form that combines techniques and principles from Bagua and Taiji into one set.
Victor Fu, the current Fu family lineage holder, has posted a video of himself doing the form here.
My kung fu teacher Andy, who was recently promoted to 6th degree black belt in Icho-Ryu Aikijutsu, said something the other day that really hit home to me.
He mentioned that unlike Aikido, which tends to strive for harmonious resolution to problems, Aikijutsu is a very brutal art. Aikijutsu fighters practice horrifying techniques that maim, blind, kill, or otherwise tend to void the warranty on the person you are fighting with.
The sacrifice is a strategy that is meant to be used in situations in which you are dealing with multiple opponents. The idea is to grab the first person you can and execute the goriest and most horrifyingly over-the-top technique you can on them. The specific example he gave was to break the person’s arm in a compound fracture and then drive the stub’s bone fragments into their torso.
The point is to let the rest of the group know exactly what they are dealing with and hopefully give them second thoughts about continuing the altercation.
This sounds like bloody bravado, but the reasoning is that you are in fact sacrificing one of the group so that the others will break off from the fight and survive the encounter. You are killing one person in the hopes of saving the rest of them.
While I personally don’t think that I have the chops to be that considerate (I fight like a kitten) the message struck with me, and I immediately saw not only how it applied to business, but how I myself had screwed up and let a team down by failing to make such a move when it could have made a difference. I feel that people that I care about are paying for that failure now.
The point here: sometimes you have to do something horrifically bad to save yourself and others.
Let’s say that you are working with someone in a tech company, and that they are a reasonably good free electron. Unfortunately, they have taken on a pet project and that project has reached the point where it is their answer for everything.
I am not speaking in the abstract: I know of one case in which one engineer was required to develop an config file-based technology that would allow customers to easily customize their information retrieval product. The engineer became so enamored with his proprietary approach that he began to move beyond simply layout customization and started defining actual programmable logic within his system.
The result was a hideous mess. The file used by the customer became a very large, arcane system of APIs devised by the developer. All binding was done dynamically, including programmatic behavior, which made tracing the code incredibly difficult. Eventually the system became so non-deterministic that even the engineer himself could not easily explain or understand how it operated.
This system was the foundation for the company’s flagship product. As new requirements were added, the engineer would satisfy them by making his system even more complex, rather than simply writing implementations in regular source code.
An initiative was recently passed in which it was decided by the company that the system was too complicated for customers to easily modify them selves. The goal of the initiative was fairly simple: simplify the file format and make the system more modular in as timely a manner as possible. The company was working on a new release and the improvements needed to be done before the new development cycle started.
The engineer in question came up with a complicated solution: develop a new, more verbose syntax and macro expansion software package from scratch. He estimated that it would be up and running within two weeks. A few people expressed some concern about the idea, but he pushed back, saying that it was the most elegant solution to the problem, and that technology he was using was the most intuitive model available for non-technical users
This was the moment at which I should have made the sacrifice, but didn’t. The plan was, in my opinion, horrible: they were going to write new software to deal with a problem that had been handily addressed by tools like m4 for more than a decade. They were replacing an already extremely verbose syntax with one that was even wordier. They were effectively attempting to put out a fire by pouring more gasoline on it.
I failed because I was unwilling to be as big a stinker as I’d have to be redirect the project. I don’t believe that I could have made a strong case against the plan without openly denigrating him to the rest of the company. The idea was terrible, it had been historically terrible. His subsystem was the single biggest delay of every release in the company’s history. It was complicated, and many people felt (although few would step forward and admit it) that no one, including the developer, really understood how the system worked any more.
I felt that this was going to slip the project even further, increase its complexity, make the system harder to use, and introduce more bugs. To actually intervene and stop this from happening would have required that I go to the executive level and say “this person has seriously jeopardized your company’s survival, and here is why. Here is every case in which he has made a decision that has hurt you. He is making a similar decision now. You can not allow this to happen.”
To put it bluntly, I would have had to sacrifice the engineers self-esteem, and perhaps his job, in order to save the company.
And I couldn’t do that.
The results would be funny, if it wasn’t actually so tragic.
Estimated time to complete: 2 weeks
Actual time to complete: 6 weeks
Original input file length: 5,500 lines
New input file length: more than 12,000 lines
Despite the simplifications the file size more than doubled! The increase in verbosity of the syntax has resulted in a file that is further cluttered and no easier to understand. The engineer in question spent an additional month that could have been spent working on the new release tinkering around with his new toy.
I don’t think that this was my fault, but I definitely know that I could and should have spoken up. Unfortunately, my desire to see the company succeed was heavily outweighed by my desire not to be a jerk or alienate the engineer. If I had worked under the Aikijutsu principle of sacrifice I might have realized that sometimes you have to do some really unpleasant things in order to save everyone else. As Rands told me: “There’s a difference between being a prick and laying down the truth. Sometimes you have to be a prick to get their attention, but when they see the truth they forget about the prick part.”
I’m not thrilled with the realization, but it will probably change how I handle these situations in the future. I really want to get along with others and be liked by them, but I’m starting to realize that being nice can sometimes cause a lot more damage than just dealing with the problems directly in the first place.
The top masters studied with many different martial artists, frequently within the same art or style.
This is valuable because, although there is The Art in its utter totality, very few people have ever mastered all of its aspects. Even those that have may only consciously emphasize, demonstrate, or teach certain limited facets of that whole. For instance, Sun Lu Tang and Fu Zhen Song ostensibly both taught the same style of Bagua Zhang (Cheng), but Sun was known for his subtlety of movement while Fu pushed emphasis on studying the ripple of power. As a result you have to look hard to find the similarities in the styles to realize that the have the same roots.
My impression is that studying Sun style Bagua teaches you to make your movements natural, economical, and subtle, and studying Fu style teaches you how to throw cars around with them.
An example from Kung Fu
Consider two of my teachers: Andy Dale and Joel Hartshorne. They’ve both taught me the same forms and applications, but always from different perspectives. Studying with both of them is really important to me, because each of them has things of value to point out in the art that the other usually doesn’t cover.
I think that if kung fu was taught in colleges that Andy would teach both undergraduates and work with PhD students, and Joel would be teaching graduate classes. Andy is exceptionally great for learning the overall form choreography, intent, and applications. Joel is usually excellent for studying the energetics and underlying physics of the moves in deep detail.
One of the “problems” with studying with Andy is that he’s so damned good that it’s hard to tell that he’s doing anything besides walking through the forms unless he’s actually got his hands on you. His circles are small and his movement is completely natural. You end up either having to have him intentionally and (for him) grossly exaggerate his movements, or looking at some of his senior students - the ones still exploring the the power in the movements - in order to actually get a sense of what’s going under under the skin.
Ironically, although Andy has been doing this for a lot longer, Joel himself is almost totally absorbed in the deeper details of the movement himself as he strives to perfect his own art. Consequently he tends to really pay attention to those aspects in his students, because the energetics of the moves is of his own primary concern. Andy, on the other hand, has really mastered these aspects and internalized them.
The point I’m trying to make here is that although they are both great teachers, I don’t think that I would have learned as much studying from just one of them, even if it was just Andy. I think that you need those different perspectives in order to get the big picture.
Applications to Software
In the exact same way, developers can benefit greatly from working with people outside of their own immediate circle. Even people far behind us in experience may have some little gems that we’ve never considered before that makes our art that much better. That said, I think that in addition to keeping an open mind, you should also think for yourself. Just because someone else prizes something highly doesn’t mean it’s not stupid. Keep the good stuff and don’t be afraid to lose what doesn’t work.
I think that we owe it to ourselves to welcome opportunities to work with strangers. If the opportunity doesn’t easily present itself, perhaps getting involved in an open source project, or founding one and looking for others to join you, might provide that opporunity.
My own teachers
I feel that I’ve had great luck in finding many high caliber mentors over the years and that I owe them all a great deal. The software masters I’ve worked with include:
Greg Bollendonk, Lockheed Martin Astronautics: emphasis on process, completeness, attention to detail, what to do when shit blows up, personal integrity, and a hell of a lot more. Greg was my first boss, with something like 15 or 20 years experience. I also worked for a year as Greg’s junior assistant in flight operations, which was a hell of a pairing experience. Greg is easily one of the single biggest influences in my career. Taught me the expression “You won’t fail. I won’t LET you”.
Steve, Paul, and Eric, Lockheed Martin Astronautics: software architecture fundamentals, UML, testing methodologies, team work.
Charles Chen and Jim Tomlinson: design patterns, UML, architecture.
Dennis Doherty, 360 Powered, Blue Scooter, and Arcessa: emphasis on pragmatics of the art, simplicity, minimalism. When to say ‘no’ to design patterns, excessive abstraction, premature optimization.
Ed Buchwalter: Emphasis on precision, formal methods, discipline in coding, test methodology.
Jar Lyons: pragmatic systems engineering, automation, reproducible regression testing.
There are a lot of other people I’ve learned from, but these individuals were instrumental in molding me. That’s my story. Who were your mentors?
An interesting read about the stages of development from initial practice to mastery.
I work seven days a week and currently haven’t had a day off this year. (This is the last year I’m going to work this hard - I Have A Plan).
Sundays are one of my favorite days to work, because I get the entire office to myself.
Don’t get me wrong, I love working with the guys on our team. The nice thing about the weekend is that I get some contemplative time and some space to think about what’s going on, where we’re headed, and what I and the guys need to be working on. Plus, I think there’d be a general mutiny if I played Dark Side of the Moon without my headphones on (like, right now) when they were all here.
I also like to use part of the time to practice and its nice to have some space to do it in. Speaking of which, I need to get some deer horn knives. I am working on the Fu Style Dragon Palm, and the deer horn knives work very well with it.
That said, I’m looking forward to seeing the rest of the crew this week.