Jeet Kune Code

There are few people I consider to excel beyond human limits in arts, sciences, and athletics. Drugged-up artists, athletes, movie stars, and scientists can appear to be, that doesn't make them any more than human. Then, there are those whose dogged pursuit of improvement and contributions to others, positive or negative, is otherworldy. One such person I consider to have otherworldy or superior skill and commitment is Bruce Lee. Beyond being an extraordinary fighter, he was an artist (more so than just that of a film actor), a teacher, and a philosopher.

If you've ever read or studied Bruce Lee's art of Jeet Kune Do ("Way of the Intercepting Fist"), and if you've ever spent a considerable amount of time writing software, has the thought of martial arts, specifically Bruce Lee's style, and your code ever crossed paths?

An idea struck while I was watching A Warrior's Journey last week, and the audio clip was played of Bruce Lee describing the need to have more freedom from the classic and sometimes rigid forms. Software, similar to the martial arts of that time, is in a rigid and classic state. We develop software according to neo-classic and static structures. In some cases, following the specification is mandatory to ensure global communication and uniform practice. But, in many other cases, people dutifully follow open standards or prescribed methodologies and in doing so become practioners or devotees to a specific programming art. Instructors, managers, and favorite online personalities become the teachers of a particular programming art.

Herd mentality and a need for acceptance drives programmers to ally themselves with one or more programming styles and arts. Eventually, ideals change and so does devotion to a specific art. A few examples: Extreme programming, OOP, scripts (Perl, JavaScript), byte-code languages (.NET or Java), any XML-derived meta-language (XAML, SOAP, WSDL, XHTML, XForms - just about anything on the W3), Visual Basic (in a world of its own), or C/C-plus. I'm grouping both languages and development styles together because they seem to separate out that way. I don't think it is the case that people select any of these languages or styles for their merits, but simply for acceptance amongst their peers or the machismo of exploration. When a discussion on the merits of programming styles ensues, most people have already made up their minds. For example, consider that multi-billion dollar companies adopt scripting languages when designing their enterprise software, or entire web sites are blocked-up entirely with a flash animation. It's not wrong to follow these practices, neither is it necessarily right.

Consider a popular product such as Microsoft Office. In martial arts, Office might be compared to all of the Karate kata's, and a competitor such as OpenOffice.org might by compared with Tai Kwon Do forms. So, you have two distinct groups, Microsoft Office and OpenOffice.org, with a unifying thread, office suite products, each executed in a different manner to provide consumers with a similar though arguably distinct experience.

On the flip side, consider the little Perl script written last week to patch up a web application. The script was cranked out in a fraction of the time it would have taken in C or C , and it was ideally suited for the job. That script could be thought of like a one-punch bar fight. You don't practice a Karate kata or a Tai Kwon Do form in a bar fight, though elements of either may be useful and certainly some katas or forms were created from lessons learned at bar fights. The same with software: a monsterous product suite is not always necessary to address an immediate issue.

The problem with the Perl/one-punch-bar-fight analogy is that it is only practical one or two times. Perhaps a whole bar-fighting style - a Perl library - develops out of the venture. However, it is still only suitable to that one specific situation, and that its roots arose from the one problem limit the growth and structure of the overall effort. In short, where the easy-to-use and adaptive aspects of Perl were suitable for the one-punch-bar-fight application, the bar-fight application cannot necessarily grow into its own Kata or form, the same way that the Kata or form may not be wholly usable in a bar fight. Maybe if the bar-fight involved a pool cue. I don't know.

A logical step-up from the one-punch Perl script and the barfight library that developed from that first script is to architect (or re-architect) an entire solution - your own kata or form; maybe your own style. Would that be the correct avenue to take? However, what is taking place within the architecture? Is the one-punch Perl script or barfight Perl library being abstracted upwards to a supposedly higher level, or are the methods and modes of barfighting being refined? Either way, additional structure is being added.

Two obvious concerns with comparing Bruce Lee and martial arts to software engineering is that Lee's philosophies tend to be centered on the individual, and those philosophies are related to fighting.

On the other hand, is an application more than a set of instructions that equate to actions over time and responses to events? An application can be simple, or very complex, artfully and skillfully designed to address a simple or complex problem. In those two respects, structure and purpose, software applications are similar to the style and purpose of Karate kata's and Tai Kwon Do forms.

I'm going to let this topic dangle for a while with the question: what is the jeet kune do of software development?