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. 

Nowadays, software architecture and agile methodologies seem to be inextricably inter-twined. Everytime I have a chance for geek-talk with a bunch of software architects, there is always someone that will throw in some of the softer issues that deal with how we run our projects, how do we estimate, something about big design up front no-no’s, YAGNI, DRY and other buzzwords. Since architecture is full of metaphorical stacks of many kinds, I thought it might be useful to invent of an agile stack. Humor me, and let’s call it the A-* stack 🙂
I think there are several layers in A-*. I have no idea what is stacked on top of what, but Here is my A-* stack as I think of it right now, and we’ll try and refactor it later to gain deeper insight into the layers of responsibility and order that must evolve out of the chaos.

• People Layer: This layer is responsible for establishing a team ethos. It is vital to creating a common work ethic in the team, shared values and principles. It is the lowest common denominator. In high conflict teams with high discord, things fall apart easily. Under these circumstances, you need to drop to philosophical introspection of your team values such as honesty, respect, reasons for existing on the project/or building the solution.
• Project Management Layer: Managing a project founded on agile practices, even those that use agile practices partially, is no easy task. There is a dedicated layer of responsibility that keeps track of project velocity, prioritization of stories, facilitating feedback and managing change. Sure, we embrace change in agile projects but it still needs to be managed within the prioritized list of stories and other constraints of the project. This is different from traditional PMBOK style project management and deserves its own layer of responsibility.
• Development Layer: This layer embraces the technical practices of the software developers. It includes niceties like continuous integration, test driven development, code refactoring, single code repositories that guarentee one version of the truth. This is, perhaps, the one layer that is best understood and have tangible actions at the code face.
• Architecture and Design Layer: This layer is more than it’s really cool acronyms like YAGNI, DRY and BDUF. The focus is on gaining deeper insight into the problem domain. It very likely shares a gray and fuzzy area with the Development Layer and that’s ok. It really doesn’t matter that we have spillage into the development layer or vis versa. As long as we focus on gaining maximum understanding of the problem domain and modelling the solution as simply as as is possible.
• Run-Time Layer: This is an oee one that I’ve dwelled on for a while. Sometimes the run-time environment really gets in the way and obstructs fluidity and rhythm in the development and architecture layer. It may well be the least agile of all layers in A-*. So, choose wisely … if you can. Let me explain a little further by example. The Ruby on Rails folk have made many screen casts that show how you can change code and you can just reload the page and, magically, the change is visible. Now compare that to someone writing EJB’s. Write, package, undeploy, deploy … it’s just painful, even if you are POJO+TDD inclined. The EJB container will bite you, eventually. So, in some respects the RoR runtime is more agile than the EJB runtime. (Aside: I think the only agile runtime in Java world is OSGi because it supports dynamic loading and unloading of classes and multiple versions classes in the same namespace. Now that’s agile!)
• Environment Layer: The place where the team work is an equal contributor to agility. From how your workpace is layed out to desk configurations in an open plan office space, it is significant. Audible and visual communication is important and this may overlap ever so slightly with the people layer. I think the environment has a dedicated layer of responsibility in A-*.
• Toolbox Layer: The tools you use can help you become more agile. I find that a flip chart, white board and multi-colored markers keeps me fluid and helps me progress rapidly, especially when I am working in the Architecture and Design Layer. We all have our special favorites that include the full blown IDE with our special key bindings, code diff tools, and even specialised items like shared whiteboards. I know of one team that has a Skype bot that acts as their JIRA interface – chatting to thet Skype bot allows them to update statuses and query JIRA. What tool ever keeps you agile has a place in this layer.

Perhaps, you have some other thoughts about what goes into A-* and what should be taken out. Maybe you have some real world insights that go beyond my meagre learning experiences. Drop me a note … I really would like to know how your A-* stacks up.