Bruce Lee would have been one awesome software developer. Even better, I would have really loved him being my coach or mentor. I came a across a site with his views on Jeet Kun Do and was astounded by the relevance to agile software development. There’s definitely something in it for everyone involved in a software development effort: from requirements gathering and problem definition, writing code and unit tests, software architecture and mentorship to attitude and values. Check out the following (anything in italics is a Bruce Lee quote) …
On Understanding the Problem or Domain

One the traps we often fall into when facing a problem domain is that of exploding the problem into spaces that we never anticipated. Often we lose track of the original problem. Users are equally guilty of digressing from the problem space. But check out Bruce Lee’s approach:

In building a statue, a sculptor doesn’t keep adding clay to his subject. Actually, he keeps chiselling away at the unessentials until the truth of its creation is revealed without obstructions. Thus, contrary to other styles, being wise in Jeet Kune-Do doesn’t mean adding more; it means to minimize, in other words to hack away the unessential. It is not daily increase but daily decrease; hack away the unessential. 

The key is to remain focused, “to hack away the unessential”, so you can get to the truth – the heart of the problem. Now our stories/use cases and release plans focus directly at the core of the problem. The truth is revealed and the starting point for test driven development is cut to the bone, it’s bare. You know exactly where to start and what you are solving.

Writing Clean Code (without smells)

So we have our problems defined, we have a some cool release plans and we start some early designs. Again, complex solutions ead to complex implementations. In agile software development we always aim for simplicity. This is exactly what Bruce Lee’s Jeet Kun Do is all about.

My movements are simple, direct and non-classical. The extraordinary part of it lies in its simplicity. 

and

One must be free. Instead of complexity of form, there should be simplicity of expression. 

I always coach teams by saying that “If you draw it, you must build it … otherwise don’t draw anything”. The simpler the solution that is architected, the higher the chance of success at the code level, implementation level, maintenance level, all levels. Bruce Lee maintains that “I always believe that the easy way is the right way.”

Avoiding Code Bloat

So we have our bare-bones problem with a simplist solution possible, and we start coding. How often, have you meandered off to explore some cool feature that your user will just love? But it doesn’t address the problem. And test driven development trys to address that. But here’s some very sobering advice from Mr. Lee:

Don’t indulge in any unnecessary, sophisticated moves. You’ll get clobbered if you do, and in a street fight you’ll have your shirt zipped off you. 

From this moment on, the imagery of having my shirt ripped off and getting clobbered is enough to keep me on the right track. At a more basic level, it is the philosophy of suppressing your ego (the “cool” recognition factor) that is so essential in reducing code bloat.

Embracing Change

You crafted your solution, you are about to go live and a new requirement sneaks in. SCOPE CREEP!!! CAN’T DO THAT!!! In Extreme Programming, you are meant to embrace change and react to it in a manner that serves the interests of all stakeholders. However, you can only react if you are flexible, if your design is simple and fluid. Bruce Lee reckons that “One should not respond to circumstance with artificial and ‘wooden’ prearrangement.” If you stick to a rigid point of view, or react rigidly with pre-conceived intent, then that essential new requirement will never see the light of day. Be fluid and react accordingly. If your design is simple and fluid, if your code is simple and fluid, you can embrace the changes.

Use of Tools and Technologies

I often come across teams where the choice of tools, technologies, languages, frameworks, etc becomes an obsession. I have seen far too many architectures where a one-framework/language/tool-will-do approach just kills off an otherwise excellent piece of work. For these situations, remember “Any technique, however worthy and desirable, becomes a disease when the mind is obsessed with it.” There is always a another way to solve a problem, or produce the same result. Don’t become obsessed with your choices. There is nothing wrong with writing core backend code in Java or C# and front end code in Ruby where a dynamic language is, maybe, a better option.Even more appropriate: “Again let me remind you Jeet Kune Do is just a name used, a boat to get one across, and once across it is to be discarded and not to be carried on one’s back.” The way I see it is that once you’ve used something, done some good, there’s no reason to be burdened by it. If your choices have served their purpose then accept that, appreciate it and move on…don’t force the same fit everytime.

Coaching Teams

So you squeezed in the new requirement and you have some happy users. You decide to build your team and be the head-geek … the ARCHITECT guy!! Now your responsibilities change, you have to guide, mentor and help the unenlightented so they too can be fluid. You impose your way on a few newbies, you tell them what patterns they should use and what algorithms where wrong choices. And you have a mutiny. Why? Because, according to Bruce Lee:

Each one of us is different and each one of us should be taught the correct form. By correct form I mean the most useful techniques the person is inclined toward. Find his ability and then develop these techniques. 

I have so often made the mistake of leading people into my way of thinking, my way of coding, my way of writing and the end result is always that the work produced is never up to MY standard. But if I take Bruce’s idea of teaching the useful techniques, and letting a newbie develop their own style, their own identity which will reflect their individuality in their creations, then I have helped a person grow. There is no other way.At the same time, you have to watch for classical symptoms in your team. Check this out:

Too much horsing around with unrealistic stances and classic forms and rituals is just too artificial and mechanical, and doesn’t really prepare the student for actual combat. A guy could get clobbered while getting into this classical mess. Classical methods like these, which I consider a form of paralysis, only solidify and constrain what was once fluid. Their practitioners are merely blindly rehearsing routines and stunts that will lead nowhere. 

This is serious stuff. I often refer to this as “cut ‘n paste” coding from Google search results. Blindly hacking away old code is not code reuse, it just creates a maintenance nightmare. Software developers need to understand that the patterns and techniques that they use are only relevant in particular circumstances and contexts. Even if the pattern is relevant to solving the problem, it may be a poor choice because of other architectural considerations.Another word of advice from The Legend on coaching people:

A teacher must never impose this student to fit his favourite pattern; a good teacher functions as a pointer, exposing his student’s vulnerability (and) causing him to explore both internally and finally integrating himself with his being. 

Now this is some serious advice which I need to heed. We often lapse into a one-way-for-all approach to coaching. Is this not a symptom of our educational methods: the exclusion of individuality for the sake of mass education? The cookie cutter approach of modern schooling – Another Brick in the Wall, Pink Floyd style.

It’s all about attitude

I’m not even going to elaborate on this. Just read the following and let it rest with you, then start Kung Fu Coding … Bruce Lee style.

Do not be tense, just be ready, not thinking but not dreaming, not being set but being flexible. It is being “wholly” and quietly alive, aware and alert, ready for whatever may come.When one has reached maturity in the art, one will have a formless form. It is like ice dissolving in water. When one has no form, one can be all forms; when one has no style, he can fit in with any style.Finally, a Jeet Kune Do man who says Jeet Kune Do is exclusively Jeet Kune Do is simply not with it. He is still hung up on his self-closing resistance, in this case anchored down to reactionary pattern, and naturally is still bound by another modified pattern and can move within its limits. He has not digested the simple fact that truth exists outside all molds; pattern and awareness is never exclusive.