f3yourmind

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

• Read More »

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.

• Read More »

Yesterday I had a really fun time running a workshop at the IQPC SOA conference on Structuring your SOA Project.  It was interesting to see that SOA is still not clearly understood and that the “silver bullet” answers are a still being sought after by a few.

The heart of my workshop centered on the theme that you cannot steer clear of business or domain knowledge, even if you try to design your services by wrapping existing software assets.  It just has to align to reality in the business, otherwise you will just create another architecture that has a fractured line to the business needs.

The other interesting theme that arose, unintentionally, was that it may well be easier to sneak in SOA by thinking in services and building some solutions covertly.  Once value is delivered and becomes noticeable, then start spreading out to the next cell … almost virally.

I summarised the main thoughts in the article on DZone at http://architects.dzone.com/articles/top-down-soa-aligning-business.

• Read More »

The architecture of business intelligence solutions is as archaic and carved in stone as a clay tablet from Mesopotamia.  It is old, stale, behind the times and controlled by a dictatorship that tries to portray a fake benevolence in all its propagandist messages.  The dictator is data itself.  Data has enslaved procedures and actions and treat them as second class citizens.  Every single time something needs doing, the data just force another action into slavery.

But everything is not everything.  A raucous revolt has been going on for a long time and there are just a few dictators hanging around clinging onto power.  The actions have created their own federated colony where they rule over the data.  “Rule” is a tough description.  Data are actually the protected citizens.  They are governed by a glorious constitution that ensures that their rights are not violated.  They behave within the guidelines of the constitution.

This new frontier is, indeed, a difficult world to understand.  It is even more difficult for the tourist companies putting together glossy brochures selling vacation trips to this world.  How do you describe a vacation utopia for something that is abstract.  Really, we can’t see an action but we can see data!  It is genuinely abstract; the action is a kind of energy that exists and binds the data.  It’s like saying that we can’t see the 4th dimension, but we understand it and know it exists because we can see the three dimensional shadows it casts into our universe.

If you’re still wondering what these extended metaphors are rambling about, then let me cut the meat closer to the bone.  BI architecture is stuck in stale techniques of moving and accessing data around the enterprise and it uses procedural techniques (the actions) to achieve this.  Everything is centered on data and data is centered on creating efficient actions as slaves.  In the world of equality - the one with the nice constitution - encapsulated behaviors (actions) protect the integrity of the data.  There are defined contracts and objects are the carriers for behavior and data.

There is so much that can be learned from this ignored world.  For example, the problems of scalability has been solved with statelessness.  Contention for shared resources have been solved with highly concurrent techniques that remove semaphores and other dead lock creating protection schemes.  The freedom to work with data in forms that are natural to the data is clean and efficient.  If data looks hierarchical in structure, then we can use use storage that naturally works with directed graphs, with lazy loading thrown in for good measure.  If data looks dimensional, then we can use a single multi-dimensional table that tolerates variant hash maps for individual columns.  If there is a need for massively parallel processing, then we can use map-reduction techniques over a distributed file system in a massive cluster of commodity hardware.

BI desperately needs change.  So throw away the clay tablets and start thinking laterally.  It’s a lot more flexible.  And if the tourist companies selling vacations want to take advantage of the new frontier, then they better understand the laws that govern this world.

Data exists because of the actions and not the other way around.  Get with the program and embrace the techniques, tools and agility of the new frontier to build better BI solutions, instead of trying to get everything to conform to that old clay tablet.  The body did not create consciousness, consciousness created the body.  Here’s the bottom line:  BI is stuck because it is a body without consciousness.

For me, I’m “just an earth bound misfit learning to fly” .   I’m still grappling with impedances and shear planes between these dichotomous worlds, trying to get others to see the value of using multiple disciplines for the symbiotic benefit of both.  I’m still “tongue tied and twisted” but a little step closer to “learning to fly”.

** Lyrics from “Learning to Fly” by Pink Floyd.

 Note: Most people know that I work for a company that crafts business intelligence solutions and that I work on the enterprise application development side of the company.  Unfortunately, I really do think that BI is lagging behind the times and that it needs a serious jolt.  The plethora of proprietary, non-agile tools and practices is still a problem.  Perhaps there are others out there that can enlighten me on the strides they have taken to built better BI architectures.

• Read More »

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.

• Read More »