Author Archives: Aslam Khan

Øredev 2008

Posted on by

I’ve mentioned it in bits and pieces before but now that the nice folk at Oredev have more or less finalised their program, I can put the down the talks I will be giving in November 2008.

I certainly did not expect to be doing 4 sessions!  It’s going to be a busy conference but also immense fun.  I hope that I get the time to attend the other talks and learn from some amazing people.  I certainly will be catching up with old friends as well

Introduction to BDD

Posted on by
I will be giving a short introduction to behavior driven development (BDD) at the XP forum on 13 August 2008.  As usual, I’m using the opportunity to subtly throw in some other practices such as coding for readability and designing good messages.  I will also touch on mocking in tests as well.

I’ve been having immense fun putting together some code examples for this talk and I hope to demo BDD using JUnit, JBehave, RSpec (using the rbehave story runner on JRuby to test Java) and JTestR (which looks like a really exciting little project).

Come along and enjoy the fun.  Details and registration is on the JCSE web site.

Update 1: The Source Code for BDD Presentation is now available.

Update 2: The presentation is now available for download here.  It’s a 5MB Quicktime movie file. It’s not a continuous play movie, so you need to click through to the next slide.

Unconventional or Uber Coaches

Posted on by

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 🙂

Power Oriented Architecture

Posted on by

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.

Top Down SOA: Aligning Business Functions

Posted on by

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.

Tongue tied and twisted, just an earth bound misfit, I**

Posted on by

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.

An Inconvenient Truth

Posted on by

I finally watched Al Gore’s documentary An Inconvenient Truth. Apart from the remarkable case put forward about the state of our planet, there was one tiny bit which caught my attention. Al Gore mentions two formulae in his presentation.

  1. Old Habits + Old Technology = Predictable Outcomes
  2. Old Habits + New Technology = Drastically Altered Consequences

Note: I may have got the wording a bit wrong but the essence is the same.

On the same weekend I was reading Jimmy Nilsson’s book Applying Domain Driven Design and Patterns (which is an excellent read, by the way). In the opening part of the book Jimmy describes what he has tried previously in his attempts to achieve good object oriented designs. By his own admission, he was not very successful. I’ll put my neck on the line and say that the problem was a case of formula 2 (but it’s not the first time I’ve been wrong :-))

I see formula 2 playing out often. A new technology emerges and we want to push the boundaries but our mindset is still a step behind. We use old habits with something new, miss the target, and sometimes create a mess of consequences which was never expected. I am certainly not innocent in this, either. To make matters worse, we sometimes use the “drastically altered consequences” to prematurely judge the new technology. The problem is not necessarily the technology, it is more likely that we used the new technology with a perspective of old habits. (Aside: Maybe formula 2 is also one reason for misuse of technologies.)

On the hand, I think formula 1 is the reason that we have legacy code and tried and tested technologies. The comfort and safety of old habits working with old technology makes a lot of sense. I still come across high quality Visual Basic 6 or Delphi applications written by highly productive teams that are not just in maintenance, but are actively being developed with new enhancements, etc.

In order to make a difference, we need to change our thinking which forces us to consciously alter our habits. It is only when we shift perspectives and behaviors will we be able to grasp a new technology or technique and make progress with minimal side-effects. The next time I am up against something new, I need to make a conscious effort to drop preconceptions and habits and make some adjustments.

There are some classic cases of formula 2 that I come across in many projects and teams. Here’s my top two.

  1. Relational/Set Oriented Thinking + Object Oriented Language = High Maintenance Consequences
  2. Stateful Client + Stateless HTTP = Low Scalability Consequences

What else have you come across?

IQPC SOA Conference in Johannesburg

Posted on by

I will be speaking at the IQPC Service Oriented Architecture conference from June 30, 2008 to July 2, 2008 in Johannesburg.
I will be running a full day workshop title Understanding How an SOA Project is Structured. It’s actually a wee bit more than the title suggests … look at the workshop page and see what I mean.

Why not sign up and join in?  It’s going to be fun 🙂

OSGi Article on DZone

Posted on by

An article I wrote which questions the readiness of OSGi for enterprise development has been published in two parts on the EclipseZone at DZone.  Read the first part at http://eclipse.dzone.com/news/there-place-osgitm-enterprise-. Watch out for the hyphen at the end of the URL, it’s significant 🙂

Many thanks to the kind folks at DZone for the publication.