Fortunately, there is always a balance in the universe. The people that balance out the power oriented architects are some of the true leaders in society, past and present. These are the people that live a value system intrinsically and that just becomes pervasive in the teams or groups with whom they work. They lead and they coach, they teach and are taught. After all, building software is a social exercise more than a technical exercise.
Here are some people that I think would have been fantastic agile coaches (in no particular order).

• Mahatma Ghandi stopped ethnic violence between Hindus and Muslims by believing in the equality of everyone. There is one quote of his that stays with me when designing software: “The only solution is that which is just for everyone”. Ok, I may have got the exact wording wrong, but you know what I mean.

• Bruce Lee was a man that sought perfection through serious introspection. He found meaning through the martial arts and when he found it, he realized it was not about the power but the subtleties of understanding yourself.  Again, something from Bruce Lee that helps me find build simpler solutions: “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”

• Nelson Mandela forgave those that incarcerated him, completely and selflessly. And in doing that, he taught 45 million people that change is possible. He has an amazing ability to make everyone feel at ease with his humility. There is no private face nor public face. There is just him. So, for the toughest bits in every design, I turn to this great man: “It always seems impossible until its done.“

Happy 90th Birthday, Madiba!

I just wish you could code as well as you coach 🙂

I have been working on a project for the last 2 years.  It’s been 2 long years.  Those of you that know me personally will know the client.  The project has been technically challenging in the rather abstract domain of data and metadata.  Fascinating stuff, incredibly fun, bordering on pure research in a commercial environment.  We also committed to being agile in this project … with the client being agile, development being agile, project management being agile, everything agile.  It could not have been a better beginning.
It has been a spectacular mess!  It is a textbook on agile gone wrong.  It is a textbook on architecture gone wrong. It is a textbook on how not to write good code.  There are many lessons to be learnt and that has been the most valuable outcome of this project.  I will be speaking on some of these agile lessons at Oredev in November this year.  For now, I just want to reflect on one single thing that popped into my head during dinner with Chris Naidoo from Psybergate last night.

Here goes!  The project has failed because of power brokering.  Too many people are fighting for power.  Power gives control and control gives more power.  The fundamental value system of the entire team (client included) has been compromised because of the desire for power and control.

The net result is personal conflict.  Personal conflict is not healthy.  Conflict in driving at solving a problem is healthy.  If there is battle for power, there is always personal conflict because politicking will happen. Teams get fractured in power alliances and off-line caucusing occurs.  Egos are reinforced and confidences are destroyed.  One person posturing superior than the other, forever trying to be top dog for the sake of being top dog.  There is never a winner in a power battle and everyone loses.

At an architecture level, as designs emerged, they were shot down like moving tin ducks at a carnival game.  The power player won and the architecture and design that went into production was that of the person that had power at the time.  It was not the team’s architecture.  So there was not sense of responsibility in the team that resulted in no pride in work delivered.  Sensible and rational thinking is lost when a leader is blinded by power and the team exists without purpose.

So we had a power oriented architecture.  We also had a power oriented methodology.  And a power oriented value system.  And power oriented development.  I am not innocent.  I did my own bit of power grabbing as well.  I destroyed myself and violated my value system … a bit.  I did realise that if I stopped fighting against power, there will be no fight for power.

I have only 3 people from the original team, me included.  One of the power brokers has moved on to a position of greater power but has less direct influence on the team.  There is a new power player in the wings.  The team is fresh, new, no power battle scars.  So we won’t fight the battle.  Too many lives have been lost.  This is not Ghandi’s passive resistance.  To resist, even passively, is to take a position in the battle.  Instead, we will resort to a value system that treats people equally, responsibly and give each person the dignity they deserve.  I wish could give that dignity back to those that have left, fallen in battle.  You know who you are.  I wish I could have done more.

Architecturally, we have resurrected one of the tin ducks that was shot down about 18 months ago.  Not by me, but by someone else who came to the same solution independently.  But it’s not a “I told you so” situation … that will start the power battles again.  So BDUF has returned, TDD has returned.  The agile practices that we cherish and shout out will be implemented again, through natural and progressive adoption, each person adopting agile practices at their own pace, guided by a value system shared by all.

Power oriented architectures and power based management does not work.  Agile embraces a simple philosophy:  think about the next person before you think about yourself.  Agile is not about loss or gain of control, it is about collective ownership.  Once you grok that and live that, then it does not matter how bad your architecture is, how unreadable your code is, or how late your are on the project. It is simple: because the team is still equally responsible for everything, moving forward out of the mess, in small steps is do-able.  There is no blame because there is no power battle.

This project has changed me to be a worse person and it has changed me to be a better person.  I hope the others on the project have the same carthatic realisation that I had with Chris Naidoo.  Chris just didn’t know that happened during our conversation.  Now he knows.

By the way, I now realised that there are many power oriented architects in many teams that I have worked with in the past.  I just did not know that it was always a power issue.  Drop me note if you have come across any power oriented architects that create power oriented architectures.

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.