Tai Chi, Software Design and simplicity

Its always interesting when different aspects of life intersect. In this case Tai Chi, Software Design and simplicity. One of the lessons I've been learning in my Tai Chi studies is the value of simplicity and minimalism. Most of the flaws in my technique end up being attempts to do to much. My motions tend to be too large and often too complex. Such large and complex motions are relatively easy to defeat.

In software as well there is the truism that the code you don't write doesn't contain any bugs. There are many possible refactorings that can increase the quality or robustness or performance of a program, but code that no longer exists takes no time to run, doesn't need to be learned and doesn't obscure the structure of a program.

The trick of course is that simplicity is hard. My Tai Chi Shifu (instructor) gives me simple instructions from which I somehow deduce complexity. Only after continued study am I sometimes able to get the flash of "oh, that's all I have to do?" as I see the simple and powerful move hiding inside my attempts.

Even though I know this to be the case I do not seem to be able apply to new moves I learn. There seems to be need to for the learning to be a process. The simple move doesn't seem to be obvious so I flounder about adding unnecessary nuances.

This makes more sense to me in software design, perhaps because I've been doing it for so long. In software I do have the ability to move fairly quickly to a simple design, and to spot the extraneous complexity in most designs. In software the simple code path usually seems to leap out of the spaghetti I often encounter.

One way of looking at this might be via the Dreyfus model of learning (see Pragmatic Programmers). The Dreyfus model describes five stages of skill:
Novice, Advanced Beginner, Competent, Proficient and Expert.

Novices need to be given a cookbook description of how to perform a task, while Experts simply do the task and might not even be able to describe how or why they are doing it. The inability to describe why can be a problem. I've had bosses ask me why I think design X is better than design Y. My answer that Design X "sings" or is "beautiful" while Design Y "feels" clunky does not tend to convince them.

I remember watching a documentary about an about-to-retire Cotton Inspector trying to teach his apprentice how to select the best cotton. The expert said to rub the cotton between your fingers and feel when it was "good". The apprentice had no idea what that meant but it was the best answer the expert could give him.

I think that most people stay in their comfort zone and thus stay within whatever skill level they've achieved. While I might claim to be in the expert group in software design I'm certainly no higher than advanced beginner or competent in Tai Chi. Hopefully this makes me a better instructor as I can relate to the students just starting to study Tai Chi.

Whether all of this eases my learning curve with Groovy or Scala (new computer languages) remains to be seen :-) It does however remind me of the quote by Blaise Pascal: "I have made this letter longer than usual because I lack the time to make it shorter".