Author Archives: Aslam Khan

Cloud Computing Zen

Posted on by

I’ve been thinking about Cloud Computing over the past few weeks.  And the business of Chunk Cloud Computing makes me feel more comfortable than the various “definitions” for cloud computing that is out there.
It amazes me that we, as an industry, find it so hard to converge on common ideas.  So, I’ve tried to formulate my own understanding of cloud computing.

I think it is …

  • a very scalable hardware platform that you share but don’t own
  • an infrastructure service that you use but never maintain
  • a computation environment that scales when you scale
  • data storage that is distributed but consistent
  • about writing applications that wire up highly cohesive, loosely coupled chunks
  • about freedom to choose and change but with greater responsibility and consequences

The last point was enlightening for me.  For sure, some vendor will pitch the “Lower your future running costs” line.  But I think Future Running Costs = Zero.  You never plan for the future but only for what you need right now.

Wow!  that is so Zenful.  Cloud Computing is about living in the moment, all the time.

Upcoming Master Class

Posted on by

I will be presenting a half-day master class for the JCSE on 27 May 2009 in Johannesburg.  It’s titled Credit Crunch Metrics and aimed at geek managers.  But it’s all about your code.  It will be an interesting 4 hours.  We will read a lot of code, look at a lot of pictures of designs.  Examine the workflow of teams.  All of this with the explicit intention of determine the cost of writing and maintaining your software.

Why Credit Crunch Metrics? Because we, as an industry, are contributing to the global financial slump.  We need to critically look at how we produce and maintain software by examining “environmental” signs that are commonly ignored.  The cost of development lies in your code, your design and your workflow.  I will show you how to look at these signs and learn from them.  And then, just maybe, we change our industry for the better – one code base at a time.  Otherwise, we might as well substitute “software developer” for “lawyer” in those old lame jokes.

Why am I targeting management in corporate teams? Because managers have the access to the boardroom and they should be fighting the battle for their developers.  So, get your “manager” to sign-up.  Better yet, come along with your “boss” and then take the battle to the boardroom together.

The JCSE and I and both hoping for 15 or more people to attend.  This is not a hard rule, but anything less than 10 will most likely force us to cancel the event.  That would be a sad reflection on the priority thinking of people in our local community.

Zen and the Art of Deck Building

Posted on by

Amazing! I just read Scott Hanselman’s blog post on finding geek balance outside of the geek world.  I started commenting on his blog, but realised I was blogging on his blog.  Here’s my own lumber-yard, geek-balance experience.
Just before Christmas, Fiona and I decided to have a deck built in the back yard.  I tossed the contractor’s quote out and decided to build it myself.  Why?  Same reason as Scott and I also specifically wanted to try my own personal Zen and the Art of Deck Building.  Fiona was naturally skeptical but indulged my mid-life crisis moment.

An apprentice in a world craftsmen.

DIY shops are intimidating.  I was an apprentice in world of journeymen and craftsmen.  I eventually found a benevolent craftsman who was humble enough to help me without judging me.  His ideas helped me simplify my design considerably and, more importantly, gave me some confidence.

Really listening to feedback. My paper design was a BDUF :-).  The moment I placed the wood on the ground, Fiona suddenly changed the location of the deck.  Short tale:  I am still building – new requirements still emerge from my main user.  Early on, I resisted every change with enormous annoyance which resulted in huge arguments.  Then I realised that the needs were real and the new requirements came from seeing how the deck looked with each step of construction.  I had an abstract BDUF and Fiona was taking in real feedback –  being agile!  And I was being rigid!

Living in the moment. I tried hard to live in the moment.  When I was digging a hole, I dug the best hole ever, deep, straight and true, until I hit a concrete block in the way.  Then my beautiful hole was a mess and I was angry at this block and tried to get past the block and continue digging my hole.  Zen moment – the task had changed.  I focused on the concrete block. Chipped away one tiny piece at a time, eventually it fractured and I could continue digging my beautiful hole.  I was focusing on the future, not the present and that screwed up my productivity.

Conflicts in collaboration. So I tried to live in the moment with everything from that point onwards.  When I was cutting wood – I cut wood and tried to get the best cut ever – to find beauty in the cut.  The one day my son, Khaleel, helped out and I got annoyed that he was messing up – it was not as beautiful as I wanted it.  After calming down and living a moment of fatherly guilt, I let him help me dig another hole and I just let him … to live in his moment.  He loved the texture, smell, etc of the sand and dirt.  I imposed my own hang-ups of not wanting to get really dirty.  I realised that he was more into having fun and I was messing up his fun – until I decided to live in the moment with him – by his values.

Finding the balance. Building the deck has been one of the nicest non-geek experiences in recent times.  It made me think differently, behave differently, regard people differently and maybe, one day, it will quietly help me build software better.  I think the trick is to find a place where you will always be the traveler in a world of benevolent journeymen.  And when you can’t find that world, then just be a benevolent journeyman in world of travelers.

Correcting my Irresponsibility

Posted on by

I have received a lot of positive feedback from many new faces for the SPIN talk I did this week.  Thank you.
But I am worried.  In the 45 minute talk, I did 5 minutes with Ruby code and cucumber.  Now so many people want to use cucumber.  Good for cucumber.

I think I should have stressed my point a lot more.

Take-Home #1: Find a way to make the life cycle of requirements part of your workflow.  Should it be a hard dependency?  If the requirements change, then do you want the build to break?  When requirements have a life cycle independent of the code’s life cycle, then you are opening yourself to waterfall-ish problems.

Take-Home #2: Agile in name and process can only take you so far.  You have to live it in your head and in your life.  For me, agile has a very Zen-like characteristic.  You need to live in the moment, absorb the feedback in that moment and adjust your next action in response to all this stimuli.  We are just like an amoeba that reacts to changes in pH.  But the difference is that we are capable of controlling our re-action or subsequent action.  An amoeba is agile by process only.

Take-Home #3: BDD can help you to change your coding and architecture attitude for the better.  It is subtle in its intrusion, but profound in its impact.  The subtley makes it dangerous.  It is not about the clever use of words, it is about the way those words impacts on your code and your resulting architecture.  So find your own cucumber and that does not mean you should go looking for another gherkin.

Perhaps I was not responsible enough.  My actions and words have affected people in a way that I did not intend.

Enterprise Scrum and Killing the Stickman

Posted on by

At the 45th SPIN meeting in Cape Town tomorrow, I will be sharing the “stage” with Karen Greaves.  Karen will be talking about the lessons she has learned in rolling out Scrum to a large enterprise.  I have a feeling that it is about scaling Scrum out to more than 10 people.  Karen has done this for 80+ people and I am certain that her experiences will reach an audience outside of Scrum circles as well.
I will also be giving a talk about Agile Requirements.  It’s about behavior driven stories that go beyond traditional, fully dressed used cases.  However, I will focus a lot more about the process and thinking behind this approach as opposed to the code behind the stories.

I always meet very interesting people at SPIN.  Please take 2 hours from your evening and join us for some great geek chat at the Bandwidth Barnyard at 6.30pm on 15 April.

Update. You can get the presentation here.  The size is optimized for iPOD and is quite viewable on your desktop as well.  The tiny bit of ruby code is included in the zip as well.

Digging into Diversity

Posted on by

A few of nights ago I had chat with Scott Hanselman about diversity in teams.  This experience and the .NET Rocks experience were really important learning moments for me.  Although you have the opportunity to “rewind” and be edited, I decided not to do that and just let me be heard as I am – unedited.
As usual, we all tend to be our own worst critics and I know I have some bad habits.  These are the ones of which I am most aware.  (a) I ramble on a bit before getting to the point and I miss the point sometimes, (b) I tend to interrupt people when they speak, and (c) I unconsciously complete people’s sentences.  Have a listen to the Hanselminutes podcast and please give me your feedback, good and bad.

The show could have gone in any number of directions but Scott did an amazing job of keeping it on a particular path.  There were some things that I thought about after the show and just want to elaborate a little bit.

The code that you write affects people on your team. Although we glossed over this and it felt like a weird application of Ubuntu, I really believe that your code impacts other people on your team.  I always joke about not carrying code to your grave.  Seriously, your code will be visited by the “second” team because your project is never complete until the “second” team comes into play after your first production release.  So writing code that is a positive experience for someone else is important.  Anyway, your code is collectively owned, and read more than written, right?

Greetings and introductions should be meaningful. The words that Scott used to describe me are nothing more than tangled mess of words that are superficially meaningful.  From that description, all you can do is categorise me by your previous stereotypes associated with those words.  Knowing people and learning how they feel at that moment in time and making that meaningful is all about discovery focused conversations.  Most people know that I really look for simple solutions to everything.  Having a conversation is easy, but choosing the right words to say is tough, especially if you are protecting yourself with a personal space wall or probing through someone’s personal space wall.

Learning is more important than being the best. I now really believe that just learning to be better for yourself is the most important thing.  It is a personal thing only.  It is not about being the top dog.  Aiming for top dog is an ego trip and power positioning becomes a vehicle for the journey.  Power destroys lives and spirits.  I have been down that road, practiced it, hated myself and been a subject of it as well.  I call it power oriented architecture.

Values and behavior compromises are contextual. We spoke a bit about clashing of value systems and I said that it is about compromise.  I think compromises only work in a context.  I have a  friend and it bothered me that he was, on occasion, a snob.  After a long time, I made peace with his snob-mode.  He was a snob in certain contexts and I acknowledged that and looked passed that and realised that the value systems and derived behavior we exhibit changes as we shift through contexts.  Ideally, it shouldn’t but we are humans and are fallible.  (Sure, we do have core values that are consistent across contexts.)  Knowing when people are applying altered values and behaving accordingly can help you create contextual compromises that can lessen the possibility of conflicts in teams.

Soft skills do not have hard recipes. Scott kept pushing me about techniques that we can use to work through these challenges in our teams.  I really did not have any.  After we stopped recording we both said that these are soft issues and there are no hard techniques.  Soft is soft. Period. It is really about becoming a better person – for yourself – and in so doing you become a better person for others.  I can’t coach this or teach this.  I can just share my experiences and thoughts on this.  And I am so very far away from not “being a jerk” as Scott politely put it.  The one thing I have seen consistently is that your “jerkness” is inversely proportional to your humbleness.

Voting for the first time in 1994 was significant. I opened the discussion about the important junction in time when apartheid was abolished and we voted freely for the first time.  This was significant because it divided our search for identity into two distinct eras.  It’s hard to manage diversity if we don’t have own identity.  Secondly, it was the most harmonious, collective experience of my life.  We stood in a queue from 8am to 6.30pm in Yeoville in Johannesburg.  In the queue we had old, young, black, white, Rastafarians, Muslims, Jews, almost every categorisation you could think.  But it was peaceful and celebratory.  It proved to me that human beings are capable of living together when we share a common ideal that we all believe in … even for one single moment.

If the real me is not Scott’s intro, then who am I? I am Aslam Khan.  I am a software developer.  I am a father, a husband, a brother and a son.  I am a neighbour, a friend and nice guy and a jerk. I am 40 and I am looking for balance.  I have two kids aged 8 and 5.  My thoughts are pre-occupied by the challenge of being a parent. I treasure my time with my family immensely but suffer serious guilts by not doing so.  My 5 year old child has a terminal disease and is classified as cerebral palsy which changed my view on many things.  My 8 year old child amazes me at his simplistic maturity and makes me realise that I am unnecessarily complicated.  I am a citizen of this world.  I wonder how many people will come to my funeral – it’s my measure of meaningful engagements.  I question whether writing software is a good way of becoming a better person.  I am hopeless at character assessments and my wife is my Deanna Troi.  I exist.

The Reincarnation of SOA

Posted on by

Anne Thomas Manes wrote a farewall for SOA in her blog post SOA is Dead, Long Live Services.  InfoQ asked for comment from SOA thought leaders and architects on this matter which created quite a stir and the usual amount of noise as well.  One of the most interesting responses I read was from Stefan Tilkov in his blog post Defending SOA.  Now I cannot resist, but give my perspective.
SOA is an attempt to create an architectural style that embodies the heart of the business – the domain.  In any business the domain is vast and so there are many subdomains or even very distinct domains.  In my workshop on Bootstrapping Your SOA Project, I defined a service very traditionally as providers and consumers connected by some execution context that hides implementation.  Now, I like to abstract it a bit more and think of services as business intentions.  These intentions cut right through the fat and get very close to the bone which is all about the domain.  That’s why I think DDD is at the heart of SOA.

Is SOA dead? Not yet but the vendors are doing a great job of killing it with implementations.

Should SOA die? No.  it’s an architectural style worth cherishing since it deals with legacy and new software at the same time, hence spanning multiple systems (like Stefan Tilkov nicely explains).

Does SOA need an ESB? Not necessarily. I think the ESB is just a pattern that happens to have an implementation called the ESB (vocabulary that sucks!).  I have seen some some really complex solutions with an ESB that would have worked just fine with, for example, a simple RMI call instead.

Is it about Business Process Management? Partially.  When you span multiple systems then you will likely do so with processes.  But it’s all about managing state across multiple systems and what nicer way is there than transferring state, i.e. being RESTful (and I am not talking about REST over HTTP).  This also suggests that you should think asynchronously as well.

Is SOA heavyweight? No.  But the vendors make it very, very heavyweight because that is the core of their economic model.  I like to think about all the little Unix command line tools that you can string together to solve a particular problem, like the FindAndDeleteAllOldLogs capability that is part of the FileManagementService 🙂

What is killing SOA? The lack of readiness for existing systems that comes from existing software development thinking in most teams.  SOA demands that you think about state, scalability, ownership, backward compatibility, testability … things that go towards creating decent API’s for your systems.  And the more vendor swagger we have, the less development teams think about API’s.

Is SOA Dead? Yes.  It was still born.  But it will be reincarnated as SOA when vendors focus on tools to help people discover domains and increase automation, and not creating heavyweight obstructions;  and when developers figure out that domain understanding is vital and writing good API’s  still count – more than ever before.

Measuring the Clarity of Requirements

Posted on by

The last two geeky conversations I had, stumbled upon the same thing – how do you measure the effectiveness of requirements in describing the business to the business and describing the specification to the developer?
So, I posed the question “How far away are you from executing your requirements?”. If you are going to go through various steps and stages to get to compilation and then execution, then every step is an opportunity for valuable information being lost in translation. If you can compile your requirements immediately then nothing will be lost.

Each additional step between requirements description and compilation and execution is an opportunity to confuse the user and the developer and everyone in between.  That’s why fully dressed use cases are not so effective as fully dressed behavior driven stories.  And that’s why BDD is very agile and a great asset in DDD and use cases just don’t cut it anymore.

Right now, my favorite tool is Cucumber.  I can execute the requirements and that raises the clarity ranking of my requirements super high.

Services are Intentions

Posted on by

I was talking SOA – again! I was arguing that modeling of services in UML, BPEL, and any other fancy acronym immediately constrains you to a specific implementation.  For example, UML means that your are thinking OO already, BPEL means that your are thinking business processes already.  But are those (and others) the best ways to model or represent a service?
In SOA, I have a suspicion (as yet untested!) that a service is closer to an intention than anything else that I can think of because it describes the latent value of the business that invariably is lost by SOA implementations and product stacks.  Now that leaves us with a problem – how do you describe intentions consistently across any domain?   I don’t know how to do this because to describe intentions in a domain, you need to understand the vocabulary of the domain.  Until we can represent vocabularies then only can we create a metamodel for these business intentions.

So how do we model intentions in a single domain since I cannot use UML (implementation!), XPDL (implementation!), BPEL (implementation!) etc?  Since the domain is constrained by its vocabulary, we need to create a language that uses this vocabulary.  And that, my dear folks, is nothing but a DSL.  If we, therefore, model intentions (the services) with a DSL, then we are in a position to translate or transform that intention into any implementation that we like.  Realistically, we will likely need additional metadata surrounding the intention described in the DSL to satisfy UML, XPDL, BPEL, WSDL, RESTful APIs, etc.

When we think of the business as what they intend to do or achieve, then we are actually working at a higher level of abstraction – at a meta-level.  That is hard to do, but if you do it reasonably well, then you have more freedom when it comes to implementation.

SOA is so screwed up at the moment and most are climbing into or out of rabbit holes because the business intentions are being ignored or forgotten far too early or thought about far too late.  Perhaps the most effective SOA implementations will be realised with a suite of DSL’s and the only toolset that you really need is a language workbench and some very skilled language oriented programmers.

Who are you targeting with your DSL?

Posted on by

I had quick DSL appropriateness argument last week for someone that was objecting about us implementing a DSL for some small part of the domain.
The argument: “Business users will never write code”.

My response: “But business users will read code”.

And to test the argument, I later emailed one of the business users with a small snippet of the DSL that we were crafting and simply said in the email: “Please check the following configurations for the client…”.

His response: “You incorrectly configured the final_costing_policy.  It should be …”

In the large, the DSLs that you create are going to be read by a larger audience than just developers.  So, like all good code, this DSL code should be highly readable, but not all of your audience needs to know it’s syntax in detail.  You create a DSL to make your life, the developer, easier.  Getting business users to understand what you are doing is part of making your life easier.  Anyway, is it not about ubiquitous language and vocabulary?  You can’t get closer to the domain than revealing data and behavior with a DSL, can you!?