Author Archives: Aslam Khan

What’s worse than BIG DUF? A BIG DIC!

Posted on by

Most agile people say big designs up front rarely pay off.  You spend so much time doing design that you delay the opportunity of feedback from real, working software.  But I sometimes do BIG DUF.  It’s not that the design is big, it’s the problem that is big.  So I need an up front big picture with just a few big parts.
It helps me conquer and divide.

That’s not a bad thing.  What I find really painful is casting the design in concrete.  When your design is cast, then your mental state is already cast in concrete too.  And that means that it is a lot harder to do the right things.  So, more gets added to the concrete slab and it’s real hard work to break anything off.  When I have a BIG DUF, I often look at how to reduce it, rather than increase it.

I don’t think it’s wrong to have a  BIGDUF, it’s worse if you have a BIGDIC (BIG Design in Concrete).  That concrete block will hurt you later … a lot.

In other words, the size of a BIGDIC does not matter, it’s the rigidity that’s the problem (— That’s so lame, I could not resist!)

ESCOT 2010

Posted on by

I have no idea what I’ve gotten myself into now, but I’ve agreed to help out the Empirical Evaluation of Software Composition Techniques workshop will be held as part of the next Aspect Oriented Software Development conference.  I doubt I will attend ESCOT or AOSD but it will be good to collaborate once more with some very enlightening people that I met at OOPSLA last year.
I guess I’ve got quite a lot of reading coming up and it will be fun to read what is coming out of the research channels and cast my own weird industrial perspective on things 🙂

Test First TDD

Posted on by

I think that TDD is getting bastardized.  If you happen to use a Unit testing framework, it does not mean that you are test driven at all.  TDD is about test first to drive the rest – design, clean code, feedback, quality, and lot more.  Using a testing framework is easy.  Being test first driven is really difficult.  You may start off with the mechanics and focus on the cadence, but you only feel the value a lot later – when you have woven it as an attitude into your fabric of thinking.
That’s why I’m giving the TEST FIRST TDD course next week.  If you want to go beyond just learning about an xUnit API and step on the path of a personal journey to changing the way you create software, then come along.  I don’t have miracles but I can do better than just shining a light.  I will step into the darkness with you and help you move towards the light.

Mapping Steve’s Mind and More

Posted on by

If you hate reading lengthy blog posts and dig the mind map view of the world, then add Steve van der Merwe’s blog to your feed gadget.  What I really like is his short quick observations and great views about software development.  But for me, it’s even better that I get to speak to him regularly, in person.  If you’re in the Cape Town area, make a point of finding him and chatting to him.  He makes ubuntu real.

97 Things Every Programmer Should Know

Posted on by

One of my contributions to 97 Things Every Programmer Should Know will be included in the book.  My good friend and colleague, Niclas Nilsson, also has a contribution which will be in the book as well.  But don’t just read mine, read all 97 and the amazing contributions that did not make it to the printed book as well.  I have know idea how Kevlin Henney managed to select these 97 things from so many contributions.

DDD Reference Card

Posted on by

I know it’s absolutely insane to try to reduce Eric Evans’ amazing book into just a few pages, but stupidity won.  I think it’s still useful as a “next to the coffee mug on your desk thing” if you’re just starting off with DDD.  So download the free Domain Driven Design Reference Card at http://refcardz.dzone.com. Small warning: it’s not useful unless you’ve read Eric’s and/or Jimmy’s book or have attended a DDD course.
I’ve tried to keep it true to the book.  I’ve aslo added a reference to a couple of additional patterns right at the end, after some quick chats with Eric and Jimmy.  Given the space constraints, I decided to leave out the CQRS work.  It feels better anyway, since this meant as a cheat sheet for people starting out.

Gotcha! (side-effects really pain a lot)

Posted on by

I just upgraded to Snow Leopard and installed buildr which failed miserably.

/Library/Ruby/Gems/1.8/gems/rjb-1.1.9/lib/rjbcore.bundle: dlopen(/Library/Ruby/Gems/1.8/gems/rjb-1.1.9/lib/rjbcore.bundle, 9): no suitable image found. Did find: (LoadError)
/Library/Ruby/Gems/1.8/gems/rjb-1.1.9/lib/rjbcore.bundle: no matching architecture in universal wrapper - /Library/Ruby/Gems/1.8/gems/rjb-1.1.9/lib/rjbcore.bundle

It turns out that I needed to rebuild rjb, the ruby-java bridge, but that failed too.

extconf.rb:48: JAVA_HOME is not set. (RuntimeError)

I was certain that JAVA_HOME was definitely set and it was pointing to the 64-bit Apple 1.6 JDK.  Digging in extconf.rb, it finds JAVA_HOME from the ENV hash

javahome = ENV['JAVA_HOME']

So, nothing weird about that too!  What’s going on?  I was installing buildr like this

sudo gem install buildr

The problem is that once you sudo, you are running with another environment, one without the JAVA_HOME variable.  So, the quick fix is simply

sudo env JAVA_HOME=$JAVA_HOME gem install '1.1.9' rjb
sudo env JAVA_HOME=$JAVA_HOME gem install buildr

I completely forgot about this side-effect.  Like all side-effects, it was painful – it just cost me an hour of  digging around looking at all sorts of other things.  But, more importantly, breaking fundamental assumptions (e.g. my environment is the sudo‘s environment) and zoning in on the root cause of the problem resulted in a very simple solution.

Forced compliance is an obstruction to discipline

Posted on by

I am amazed, yet again, that people try to force others to comply to a process, standard, or whatever.  The traditional justification is to ” have governance otherwise everything will fall apart”. Surely, we have learned enough from spectacular failures that governance that does not give people an opportunity to exercise self discipline.  When you give a person a chance to develop personal discipline, then forced compliance is unnecessary.  With forced compliance, we force people into ignoring their own discipline because the system will “sort” it out for you.  It breeds an attitude of “the system failed me and it’s not my fault”.
This discipline I am talking about is a personal attitude to everything.  Some things may be the discipline to

  • not check in code that is broken
  • fix your own or someone else’s broken code
  • find options for looming failure
  • be accountable when you’ve accepted responsibility
  • admit error when you make a bad judgement
  • commit to learn in the face of ignorance
  • share because you just should anyway

Of course, I am being deliberately idealistic.  But wouldn’t it be really nice if everyone just accepted discipline as something that needs to be developed personally.  Imagine it for a moment … so many XP values and principles seem a lot easier to adopt.  Just imagine it.

A forced compliance style of governance is a lot about trying to compensate for lack of trust and admitting that we are more likely to fail than succeed.  On the other hand, discipline is not pain, suffering and anguish.  It’s only sadistic if you implement discipline for nothing.

In ubuntu coding, discipline is a necessary quality.

Readability is the real (re)usability

Posted on by

Last week on the factor10 DDD course in Cape Town, the question of reusability came up again.  It’s the same old object orientation promise of “Just do OO and you get phenomenal reuse for free”.  Today, I was refactoring some code with another developer at a client and I extracted some lines into a few private methods just to clean up a really fat loop.  The initial reaction from the other developer was “That’s an overkill because you won’t reuse that method”.  My spontaneous reaction was “Readability is the real reusability”.
It’s true, the method won’t be reused.  It’s also true that most us were taught in some Programming 101 course that you should create a method, function, procedure only if you are going to call it more than once, otherwise just leave it all inline.  I value ubuntu coding, and so I have learned to unlearn that naive rule.  When I make my code more readable, I get more reuse out of it.  The reuse I value is not really about the number of repeated method calls or number of inherited classes.  I value the increased reusability that is achieved when more developers are able to read my code and walk away understanding my intention, clearly and unambiguously.

Let me put it another way.  Your code is a representation of your model.  Your model should be used to drive all collaborative discussions about the solution.  That’s where you get the real reuse in your model.  If people can’t understand your model, then your model can’t be re-used for further discussions.

There are no boundaries, just forces

Posted on by

I shared by thoughts on people dynamics and how it affects success of software development projects with Yuanfang Cai yesterday.  In particular, I was explaining my thoughts on how diversity in a team affects the performance of a team.  When I talk about diversity I mean a lot more than just culture, language, and timezone.  I also view diversity in terms of value systems, political affiliation, economic position, overlapping worlds (such as work world overlapping with home world).  But my weirdest interpretation of diversity is that of diversity based on team boundaries.
Traditionally, each team has a boundary.  This boundary determines whether you are included or excluded from the team.  Sometimes, the inclusion and exclusion rules are clear, which is a good thing.  Sometimes, it is not.  Regardless, the boundary exists to eliminate diversity.  But, there are too many edge cases of people being brought into the team for a short while, then leaving.  The position taken is often “Joe is not part of the team, but sometimes we need him to join in so that we can …”.  Well, teams don’t work like that.  Let me rephrase: GOOD teams don’t work like that.

What I explained to Yuanfang was that I don’t think a team should have boundaries at all.  Instead, everyone is part of the team.  However, some people have a strong force that attaches them strongly to the team and others are attached by much weaker forces (like Joe’s part-time involvement).  When, you think of the team constructed via these forces, then the team can still work from one value system.  Why?  Because the degree of adoption of the value system is independent of the strength of the team forces.

Try it out and, maybe you will get greater harmony in the team and increased collaboration too.