I see many people freak out at the mention of any change. I often do that too. Why? Because it forces me out of my comfortable existing neural wiring. Now I try to view change as a contextual adjustments and a little bit of re-wiring for comfort sake.
Hmmm, as I age, I think the slight contextual shifts that I go through now feels less like the massive catastrophic continental shifts. Much nicer.
Category Archives: Software Development
Ambler, Hundermark and now my Two Cents
Peter Hundermark has a nice summary of the talk on Agility at Scale that Scott Ambler did in Cape Town a few weeks ago. And Scott had the courtesy of straightening out some thoughts on Peter’s blog as well.
Padding End Dates. End dates exist because of our immense desire for closure. We cannot tolerate the thought of not knowing when something comes to an end. So we would rather stick in a fake end date than no end date. Are you prepared to stick an end date on your life, just so that you can create a finite sense for someone else?
Optimizing the whole. For me “whole” means everything, your workflow, your thinking, your architecture, your code, your communication, … everything. But just drop into the code bit for a moment. The reason TDD works is because it gives you feedback quicker. It is not about the red-green-refactor process alone. You have to be agile in your code and design too. And linear problem solving results in linear code styles and mindless red-green-refactor results is not agile unless you are 100% immersed in the moment of exploration and discovery. Overall, I think optimizing the whole, getting rid of wastage, lean, etc is all about finding the right balance – at that point in time, in that context.
BDUF. How much of upfront design is big design up front? It depends on the context and the principles on which your software development is based and also who is affected by the software that is produced. I like the phrase “little too much design up front” and “little too little design up front” which I picked up in this post by Kent Beck. (Please don’t acronymize that!). That particular post was simple and extremely profound view, for me at least.
Just when I thought that I am making progress, I feel like a noob again.
Learning Rules for Noobs
The unfortunate human characteristic in all of us is that we like rules when we’re in a new and unfamiliar situation, and hate them the moment we think we are experts. The problem is that rules are great for creating concrete things. If you want to build this then: do a, then b, if you have a c then do d otherwise do e. But it does not work with creating abstract things. And software development is all about building abstractions.
In the past few weeks, I’ve had a few instances where I realized that some people were, basically, asking me for DDD rules – steps for building an aggregate, when and how to use the specification pattern, etc. There are no rules for the noobs for these things. But I think I can constrain the environment so that the noobs can focus a bit more intimately with these aggregates and specifications. One rule I put down was “When working with the following … don’t work outside of this Java package”
Essentially, my proposition is that rules for noobs should constrain the learning environment, not the subject being studied.
Cloud Computing Zen
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.
Zen and the Art of Deck Building
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
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.
Digging into Diversity
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
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
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
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.