Author Archives: Aslam Khan

Geek Dinner Feedback

Posted on by

So I did go after all and it turned out to be a rather interesting event. There was a great turnout of about 60 or 70 people. The venue, The Wild Fig, was great, wine was sponsored by GETWINE (very generous of them), and WiFi hotspot by SkyRove. The talks were well timed, not too long or short, with a good mix of socio-political-technical chatter. The format was perfect: Quick intro to everyone, orders placed, 2 talks, starters, 2 talks, main course, 2 talks, desert, open mic. Just perfect!
Antoine van Gelder did a silent (self-inflicted-ducktape-on-mouth) talk on the One Laptop Per Child project. The point: children are taught to learn in silence, without expression. But expression online cannot be silenced. Very noble cause which I hope will get the time/publicity it deserves amongst the other fundamental challenges (hunger, health, etc) that children and families in Africa face daily. And he brought one of the laptops along for us to play with.

Bryn Divey did a well timed Python-bashes-PHP bit. If you ever liked PHP, you’d wish you didn’t. Very convincing argument against PHP, but I am still not convinced about Python. His delivery and style reminded me a lot of Dan North.

Tania Melnyczuk did one of the best project management flyovers I have seen. Nice to see that she touched on agile methodologies relevance in project management. At least I know one more project manager that I do not have to explain what a user story is and why I need to do a release planning session.

Nick Coyne did a really nice intro of Ruby on Rails and managed to evade the obvious Ruby-is-better-than-Python-is-better-than-Perl-we-all-hate-PHP dissidents. What was great to see was his pitch for having fun again and writing beautiful code. Something I relate to a lot.

Alan Levin spoke about the lack of socio-political endeavour attributed to lack of caring. In this instance, caring about bandwidth costs in South Africa … we all want more bandwidth cheaper but we really do not put our energy to make it happen. Very true. Are social and consumer causes dead in the post-apartheid South Africa? Or is it that only fundamental human rights violations warrant the mass protests of the 1980’s in which I grew up? Sri Sri Ravi Shankar will most likely pose the simple questions: What is your responsiblity and for what are you responsible?

Ian Gilfillan  did a bit on emerging mind games such as Go and Marabaraba (sp?).  He reckons that checkers, chess are dead ever since Deep Blue overpowered the great Gary Kasparov.  It was nice diversion.

The open mic spot was seized by Robin Ronne who chatted about the Ripple project.  I did not get the low down but it was something along the lines of a social network where the trust relationships have credits attached so that you can cut out the evil banks for all your money based transactions.

Neil Blakey-Milner mentioned that he will like to pull together an event in September over a couple of days.  Sounded like an Open Spaces style event even if he did not use those words.

Overall: Interesting event.  Was a bit disappointed initially with the lack of detailed technical content.  Upon reflection, I reckon that the content suited the format.  Highly recommended.

Reflections on the JCSE Agile and Architecture Talk

Posted on by

It was really good to be part of a very topical subject at the JCSE Architecture Forum last night.  While these discussion are so valuable, the things that surface can only be glossed over, largely because of time constraints.  I end up feeling a very satisfied and energised but a part of me feels a bit hollow.
So here are some of the things that surfaced at the Forum, and my narrow, unworldly opinion on each (i.e. I’m just trying to fill that hollow feeling).

When we talk about architecture, we need to define what we mean by architecture?

In my talk it was a very simple view of architecture which, thinking back, I should have disclosed very early.  I am now applying from Kent Beck who talks about mutually beneficial relationships.   So I think of architecture as the mutually beneficial relationship between two or more things.  So what is a thing?  It could be  lines code in a method, methods in a class, classes in namespace, namespaces in code base, binaries in an application server, application servers in a cluster, … see where I am going?  Architecture is about creating beneficial relationships, and the 5 things I discussed are based on this view.  If you don’t know anything about the things, then you cannot create beneficial relationships.  From an agile perspective, the beneficial relationship that you create should only be beneficial based on your knowledge right now.  Tomorrow your knowledge changes, so the relationship may not be as beneficial as yesterday.  Time to change.

Building infrastructural architecture independently of functional requirements…

I am not convinced of the benefit of this approach.  In my limited experience, every business need defines the constraints or needs of the infrastructural architecture.  I find it hard to find the point of departure, yet there is a school of thought that suggests that function is orthogonal to the architecture.  Perhaps I just don’t understand this.  However from an agile perspective, I want to release early and there are many constraints on infrastructure from the business (for example, administrative processes like procurement of hardware).  I like to understand what these are early on, reach agreement on what we can release at the earliest and design accordingly.  Perhaps the first release is on lightweight infrastructure and that means we “limit” scalability.  So, I don’t design for beyond what I know is real.

Model Driven Architecture …

My view is more philosophical and abstract.  What is a model?  For me, a model is something intangible.  It is a way we understand something.  But we represent our models in many ways.  Through words in written or spoken conversation, in unstructured pictures, in structured notation like UML, even code is a representation of a model.

What do we mean by driven? I view it as a something that takes an input that produces an output.  In this case, we take an input, the model, and produce an output, an architecture.  So, I take an understanding of problem and use that to derive an architecture.  So, that’s nothing new here.  However, I don’t like to confuse driving out an architecture from a representation of the model.  That’s different.  Now we are going beyond thought processes  into mechanical processes.  Then the challenge is about how to apply the feedback to the representation of the model – and that is what will make you agile.  Too much for my small brain.

Plumbing …

Yup, we do too much hand crafted plumbing!  It’s something that we have been working on for a long, long time.  I think convention over configuration, dependency inversion, meta-programming are all attempts at addressing this problem.  Some early success that I have experienced is on taking a polyglot approach. I am not talking about mixing general purpose languages on one runtime only.  I am also including domain specific languages. I’ve had some early success where using DSL to describe functional intentions and then generating a large portion of the plumbing.  Where I’ve suffered is when I mix concepts from different domains.  There is the domain of plumbing and the domain of the business.  Whenever I’ve mixed the two, it pains later rather than sooner.  Right now, the only way I’ve had some success is with aspect orientation and meta-programming.

@StatelessSessionBean …

Chris Naidoo is right.  That thing called J2EE and subsequent versions is just horribly broken.  It’s broken encapsulation and a whole lot more.  The fact that we now must use an annotation and not implement an interface is immaterial.  Both result in the same pain – mixed concepts (see plumbing above).  Annotations should be specific to the business such as @RecalculateCostsOnRerouteOfCargo can be used as an interception point for injecting a rule on a class or method.

I would go even further and say that the POJO JavaBean specification is also broken.  Why on earth must I have a no-argument constructor and accessors and mutators.

Last thoughts …

I may have missed some of the other discussions but these are the ones that I woke up with this morning. In general, my observation is that we need to be very concrete very early if we want to be agile, even in architecture.

Resurfacing Diversity Challenges

Posted on by

I got a tweet from Clive Seebregts which pointed me to an InfoQ article that made reference to an old Hanselminutes podcast that I did.  It’s nice to see that diversity is not being left in the wilderness and that other people are thinking about it again.  It seems like some people are trying to promote diversity and others are trying to manage the challenges of diversity.  Hmmm, somewhere there is point of brutal contact, but it will be for the good.
BTW, digging around on material diversity in agile teams I came across this video.  I didn’t know it existed at all.  Suddenly, the references to the FIFA 2010 World Cup seem sooooo dated.

Modeling out Loud Deep Dive

Posted on by

For those of you that attended the Modeling out Loud deep dive at the S.Africa Scrum Gathering today, here are some things that I discussed.  It’s in no particular order, and it only makes sense if you attended the session.

  • BDD Stories that are authored outside the team contributes to a hand-off which influences design decisions.
  • Because we understand something does not mean that we know how to design it.
  • Be aware of when you are analysing and when you are designing.
  • Be concrete and abstract late.
  • Use the scenarios to close the loop with product owners, stake holders, etc.
  • Developers should write BDD stories and scenarios.
  • We are less ignorant at the end of the sprint than at the beginning.
  • Use code to close the feedback loop for your story.
  • A story and it’s scenarios can be a representation of your model, just like a picture, UML, test code, production code.
  • Seek out the behavior and express intentions.
  • Use the value statement to explore alternative needs.
  • Product owners should not write BDD stories
  • Recycle stories if there are scenarios that you cannot commit to.
  • Keep out the technical jargon.  The moment you get technical, then the story shifts to an implementation.
  • Evolve and accept that it is ok to change … your story, your scenario, code, anything.
  • Login is not a story

There was a lot more which we all discussed, so feel free to add what you got out of it as a comment for others to grab.

The slide deck which contained the code example is available at http://bit.ly/bhNkvQ.

And lastly, thanks for joining in.  I sincerely appreciate you making the time.

Remember that writing stories is a really difficult thing to learn, because is design is hard.  Persevere.

Geek Dinner

Posted on by

A colleague of mine, Anne Botha, gave me a heads up on the Geek Dinner that’s happening in Cape Town on 28 May 2007. It’s been 2 years going on 3 living in Cape Town, so maybe it’s time to join the geek crowd. From the blogs about past dinners, it seems to have a good balance of high quality techie talks and social networking. It will be interesting to see how this compares with the Software Architecture Workshop (convened by Jimmy Nilsson) that I attended in Arosa, Switzerland earlier this year.  Jimmy’s event was over over three or four days as compared to one evening.  I have a feeling that the tech talk at GeekDinner will be of equivalent quality to that at SAW.

Behaviour Driven Development at Cape Town Geek Dinner

Posted on by

Earlier this year I got to hear about Behaviour Driven Development from Dan North at the Software Architecture Workshop in Arosa, Switzerland.  Since then, I’ve been using BDD to various degrees on various projects, and I have to say that it works for me.A few nights ago, I presented BDD at the July GeekDinner in Cape Town. I had no idea how this approach will be received, but I was quite surprised by the interest and chatter that I had with others after the talk, especially around rbehave. I wonder how the conversation would have turned out had I used JBehave examples instead?The rest of the GeekDinner was, as always, an interesting mix of techie, geeky things. Jonathan Hitchcock has a nice wrap-up of the evening.Download my presentation here (PDF format).

Intention Revealing Names

Posted on by

Update: A small elaboration of this has been published on the Architects zone at DZone.com.  Read it at http://architects.dzone.com/news/intention-revealing-designs.
The value of naming of variables, methods and classes is highly underestimated. Given that code is read more than it is ever written, the readability of your code will get more attention than your original thought process that led you to the code. I will be so bold as to say that the reader really does not care how you arrived at those lines of code. The reader is actually focused on what you mean by the code and not how it does its magic.

Often the problem lies in carrying implementation details into the name of the intention. For example, assume you have designed a social network as a directed graph and you want to find all circles of friends that are in this social network (e.g. Joe knows Mary who knows Peter who knows Joe). Since it’s a graph, we can find all cycles in the graph, or closed loops. So, you write code such as:

class ObjectGraph {
  public Collection<CyclicGraph> findCyclicSubgraph() {
	  ...
  }
}

class CyclicGraph extends ObjectGraph {
  ...
}

This does not reveal any intention of finding circles of friends nor does it surface the domain adequately. The same code with intention revealing names just reads better:

class SocialNetwork {
	public Collection<SocialNetwork> findCirclesOfFriends() {
	  ...
	}
}

There’s a subtlety hidden in the refactored code. Both the circle of friends graph and the graph of the entire network are of the same type. SocialNetwork is a composite and has the advantage that all operations executed on a composite will yield a composite of the same type as well. In other words, all operations on SocialNetwork will yield another SocialNetwork. That is also intention revealing design as well as a bit of suppleness.

Here’s another example. You wish to set a boolean to indicate that an object is dirty in your cache.

public void setDirtyFlag(boolean dirtyFlag) {
	this.dirtyFlag = dirtyFlag;
}

But refactored with intention revealing names, the purpose is now explicit.

public void dirty() {
	this.dirtyFlag = true;
}

public void clean() {
	this.dirtyFlag = false;
}

Whenever you are writing code, ask yourself: “Is my intention clear and unambiguous?” If the answer is “No!” then your code is most probably lacking readability. There are refactoring techniques and many patterns that can be used to increase the suppleness of your design, but just spending a few extra brain cycles on the names that you use in your code can make an enormous difference in displaying your intention and not your implementation. This alone will increase readability and reduce maintenance of your code.

Introducing the A-* Stack

Posted on by

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.

Launching the Services Support Group

Posted on by

“Hello.  My name is Hope and I am a Service.  Last week I was asked by a View to do something.  I told the View that I can’t do it.  So he asked the Fat Controller.  The Controller sent me the same message and I just took exception.  What kind of service does he think I am?”

“Hello Hope.  We are glad you joined us.  You are not alone.  Look around the room.  We’re all struggling to find our own identity.  Those of us that have been around for a long time are still recovering from being forced to convert DomainObjects to DTOs.  The more recent ones feel like meaningless proxies, and last week we had a guy who thought he was a Service but he was just a HelperClass.”

“It’s as if I am losing touch with reality.  My own DomainObjects don’t even interact with me directly.  Now processes want a piece of me too.  I think I am schizophrenic.  Am I now a process?  A wrapper point for Transactions?  I swear to you, there are days when I even think I am a stored procedure!”

“Ohhhh, noooo!”

“But I know who I am. I am a Service.  I like working with DomainObjects.  They need me.  Somethimes they can’t do everything on their own, so I help out.  I complete their world and it makes me feel like I belong in the right place.  One guy even refactored me from the domain package to a services package.  Can you believe that!  Actually, now that I’ve said it aloud, I am not surprised that I feel more and more disoriented.”

“Disoriented?  Oh boy, we really can’t help you here.  You see we’re recovering from abusive Controllers and Views and when you told us the story in the beginning, we thought we could help you but you’re just a …”

“But that story is true.  Apparently there was this Process on other side of  this MessageBus that needed something and he asked the Fat Controller who got involved with View and then I got sent this message and …”

“WTF?!!  The Process asked the Controller…”

“Yeah!  You won’t understand … it’s after your time.  It’s really a WebServices Controller but I hear that he also feels abused and just wants some REST.  You think there’s a support group for Controllers?”

“Wait.  I remember this other crowd … uhhmmmm … sorry – those weren’t Controllers, those were Presenters working with Models and Views, but I used to be confused as a Delegator and I can …”

“You’re NOT HELPING!!!  I told you I am a Service!  And I am confused!  I want to be part of the domain again!  I feel disoriented!  And I …”

“And I told you that we can’t help you.  The truth is that you are DOA.”

“Dead on Arrival?”

“No! DisOriented Architecture.  You know … they don’t know where to put that, so it becomes a service.”

“But, but … I am a Service … <sniff>”

“YOU WERE NEVER A SERVICE!  YOU’RE ONLY HOPE!!!”

Stranger Danger in the Cloud

Posted on by

There will always be someone who will scream that Cloud Computing is new.  And there’s someone else that will tell you it’s old-school-been-there-done-that.  And there will always be some vendor that will try to sell something too.
Since we shrink in body and mind to the state of children when thrown into a new context, beware of stranger danger.  It’s tempting to follow strangers for cheap candy in the cloud.

And yes, like SOA, we’ve seen and done this before.  But I think it is important that we let the passage of time to gel our experiences and ideas over and over again.  Why?  Because contexts change with time and we can use new contexts to innovate again and again and again.

You’re allowed to think … for yourself … and decide … for yourself.