Author Archives: Aslam Khan

Fat is the new Thin

Posted on by

During a factor10 virtual coffee break, Niclas Nilsson and I had a chat about what’s going on in web app land, on the browser end of the landscape. So this is inspired by his observations and him ‘pushing’ me to write this.
Recently, I’ve seen a few people searching for the holy grail of the ubiquitous browser UI.  The usual suspects appear: Silverlight, Flex, JavaFX.  Then I always suggest “What’s wrong with HTML, CSS and JavaScript.  You are writing a browser app, aren’t you?”.  And I get this weird, one raised eyebrow look.  So, in response to the one-raised-eyebrow look, here’s what I have observed. (I use the word model and fat below, maybe it’s the wrong usage, but I think you’ll get the gist.)

In the early days of browser apps, everyone was trying to write fat desktop apps in HTML.  And that went horribly wrong because the programming model was different.  We eventually figured out page based, disconnected apps in the browser, then someone did the AJAX thing and we had out-of-bound HTTP requests and in-place DOM updates.  Another small twist in the programming model.  But we had already made the transition to a new programming model and AJAX was not a radical change.

Now we have Silverlight, Flex/Air and others.  They happen to run in a browser, but there’s nothing browser based about them.  Yes, they all let you interact with the DOM and run some JavaScript too.  But these apps might as well not be in a browser.  In fact, that’s now pitched as a super great feature: your code can run inside and outside the browser.  The programming model is different.  No matter what the marketing folk say, I think the in-browser feature is a clever adoption scheme.

The truth is that this new thin is actually fat, FAT, FAT!  It’s just fat and disconnected.  That is all.  My advice for those that want to go this pseudo-thin route, is to just write your app to run outside the browser.  Just forget about the browser.  If you want to use the browser, then go back to HTML and JavaScript. The common counter statement is that these clients get rid of browser incompatibility issues.  If you really want to get rid of browser incompatibility issues, then don’t use a browser.  Simple.  And these confused thin clients will let you do that.

But the part that really scares me is that the fat code I have seen so far reminds me of unmaintainable VB, Delphi or PowerBuilder code.  And there are other scary things too.  For example, the Cairngorm framework for Flex is based on a singleton pattern, but the underlying language does not make it easy to create singletons.  Imagine all the code to create a singleton just to get the framework to work.  And these frameworks are not very DRY either.  Somehow, it seems like a new group of developers are writing these frameworks and they have not bothered to learn from 10+ years of web UI framework lessons.  The good news is that code maintenance and framework quality issues are solvable.

But the game itself has changed.  It’s not a case of new rules in an old game.  That’s what caused the mess in 1999 with HTML.

By this time, most people either close their eyes or raise the other eyebrow at me.

Trust Everything

Posted on by

Trust has popped up in so many of my conversations recently.  It came up at home, at a new school that Lia will be starting next term, in the DDD course that I gave earlier in the month, in Peter Hundermark’s scrum master certification course.  And I got a one line email that said this.

The entire world lives on trust. Every aspect in life moves with trust.

The more I think about situations in life that will prove this statement false, the more it seems to hold true.  Even in design it holds true.  Your most fundamental architectural decisions are based on trust and the implementations of that architecture work because of trust.

It’s true for code too.  If you don’t trust the code on which you build or depend, then you might as well write everything yourself, and give up your place on your team.

I was thinking about the AOP with DDD tutorial that I will be giving at OOPSLA this year, and this trust thing came up.  Here again, aspects and the classes into which they get woven, need a trust relationship.  It may seem like a stretch to make that statement, but I think it holds true again.

So, how do you gain trust?  I am not sure, but I think you have give up something first.  Maybe you need to show your vulnerability first, then it becomes easier to let someone into your space.  Then, perhaps, they will let you in to their space too.  When ego walls are erected, then trust finds it hard to grow.  By ego, I don’t mean arrogance, I mean awareness of your self that you hide from others for fear.  Perhaps, it is only when you show your true interface, that the other will worry less about hidden agendas.

In code, trust lies in interfaces and types, not in implementations.  It’s really about trusting the implementation that makes types worthy.  When you trust the type and send it a message and it behaves as expected, then you trust it.  If you request something of an abstract type and the message was received by an instance of a subclass, then you expect the subclass to behave like the abstract type.  You don’t hope that it does behave consistently, you trust that it does!

Trust is tied in with ubuntu too.  You can’t be part of a community nor allow yourself to be defined and shaped by the people around you, if you can’t trust them.  I think ubuntu coding needs trust as one of it’s values.  It’s already a value in XP, and Scrum, and families.  It needs to be in teams, and organisations, and communities and nations too.

Flowing in the Waves

Posted on by

I just had a quick Google Wave experience with Willem Odendaal and the experience of seeing the other person type was a bit weird for both of us.
Lesson to both of us: Think before you wave!

Also, I have to remind myself to not think about waves as email, or tweets or instant messages. It’s just something else! And it has a different spin on the time dimension of communication.

I suspect that Google Wave will force us to be better at the way we communicate, how we express ourselves and the relevance of the content to the conversation.  I can imagine a wave growing over time that describes a story started by a domain expert with feedback from a developer and a nice cadence emerging between them.  It all is in one nice wave, with playback that tells you how you got there in the first place.  I wonder if this will have an influence on effectiveness of remote pairing?

I also have a feeling that if you’re a waterfall type of person, then waves will not have an impact on you.  It’s all about feedback and dealing with the changes, which is at the heart of agility.

Now I just need someone to wave with to try out a slightly modified development flow.

Two Angles to Sustainable Pace

Posted on by

At the Scrum User Group South Africa meeting last night Marius de Beer did a really good talk about Software Development Practices.  It’s been a long while since I saw anyone attempt to draw so much from such widely spread corners of wisdom.  In one slide Marius mentioned the practice of Sustainable Pace.  Many take the view that this is about cutting back on working overtime and that it supports the principles of energised work, and work-life balance.  Marius did make the same point, and it is correct.
But there is another angle to Sustainable Pace.  As a developer, you need to build a rhythm, or flow.  It’s a cadence that you establish as you are writing code.  It’s a cadence that TDD helps you establish itself.  This cadence is also sustainable pace.  And one thing that kills this cadence and your pace in a flash is a mid-stream meeting.

In the panel discussion afterwards, there was a question at the end regarding ways to reduce the number of meetings which I just glossed over.  If you schedule meetings with developers for only the first hour in the morning, you not only reduce the number of meetings but, also, you don’t destroy the sustainable pace built up from the morning.

So, don’t think about pace as just working 7 hours a day, it’s about what you do in the 7 hours that matters.  Get the rhythm going and be anal about things that can kill your flow mid-stream; especially meetings.

Testing is just a laborious pain in the rear

Posted on by

I thoroughly enjoyed Karen Greave’s talk on Agile Testing.  She had just about 100% coverage (pun intended, groan).  Yet, testing is really a pain in the rear.  Testing is execution, and Karen was dead-on right, that automation is the path to follow.  Computers are very good at testing.  A computer does what it is programmed to do, and it can test the way it was programmed to test.  It’s simple: if testing is your constraint, move that constraint away from testing by automating.

Now, you have to deal with the constraint that shifted to the next point: test authoring.  While testing (i.e. execution) is just a passive, laborious effort, test authoring is a very creative, active exercise.  It is actually an exercise in confirming a shared, common understanding.  Kristin Nygard said “To program is to understand” and test authoring is a programming exercise.  That’s why outside-in, behavior driven development style scenarios are actually tests, coded in a human language.  The act of authoring a scenario proves your understanding and the expected working of the software.

This is why I separate test execution (passive) from test authoring (active).  And Karen said that early feedback is good (right again), which is why I author my tests very early.  I’m extreme about this.  I test first.

Coding for Enlightenment

Posted on by

Jimmy Nilsson asked me in an email a few days ago “How’s life?”.  I’m sure it was just a regular, friendly question, but I gave him a “life” answer.  It was not spontaneous but something that has been brooding in me for a while.   It is about things that I have been trying to do for a long time.
Here’s a few splintered thoughts from my email exchange.

  • Enlightened, for me, is about happiness that comes from being content; unenlightened is just trying to be happy.
  • There are many solutions for every problem, whether I am aware of them or not; and the problem has already chosen the best solution, but I have not found it yet.
  • Code from my heart because I should trust myself first.
  • Be part of the exploration, not just an observer.
  • This moment is more important than trying to figure out how it impacts the future, because I can deal with the future in that future moment.
  • Passion is constant whether I succeed or fail.
  • Let the project plan me, by bending to suit the situation not and not bending the situation to suit me.
  • The code I write knows everything, because every line of code has an impact on someone else or some other piece of code.

Now I’ve decided to actively explore why I write code, or why I wish to continue doing what I am doing.  I am not sure what I will uncover in this exploration, but I know that it will be very personal.  I don’t even know if it will be worth sharing, that’s why I am sharing so early.  It just felt right.

I think it will be really tough, but I take solace from my 9 year old son who told his 6 year old sister “Getting hurt is part of playing”.

PS: I don’t think Jimmy will ever ask me a “How’s life?” question again 🙂

Technical Debt Does Not Exist

Posted on by

Metaphors may be a good way of getting to grips with a new domain.  It allows you to imagine the behavior of something that you don’t quite understand (yet) in terms of something with which you are quite familiar.  That’s were it should stop. I hate metaphors that extend beyond their purpose.  Once I have a good enough understanding, I drop the metaphor.  My reason is simple.  Metaphors force me to do a lot of energy sapping context switching.
Technical debt is one of those metaphors that have been extended so far, that it is believed by many to be something tangible.  Let’s get real here:  Technical debt does not exist.  It is just a metaphor for us to realise that our code base may cost us more money than it should, and that is a future view.  Sometimes our metaphors become euphemisms, and then it is dangerous.  When it comes to technical debt, the less I think of code problems as debt the more I am able to face the problems head on.

Ironically, I did a talk recently on dealing with technical debt.  My fundamental position is simple.  Either your code base has things that exist as a result of broken principles or it does not.  The more principles you break, the more potential problems you have in your code. It is not a problem right now, but it may be a problem in the future.  This future can be a minute away when I run my next test or a year away.  If the future is infinitely far away, then it is not a problem at all.

My first prize is to not break principles, so I don’t create potential problems.  My second prize is to deal with real problems and just leave the potential problems for the future.

(Warning: I’m drifting into my enlightenment self-reflection, so feel free to stop reading now.)

If I am part of the exploration that is looking for a solution (living in the moment and not outside it as an observer), then I should be aware of principles that I am breaking and I should change course immediately.  If I am part of the exploration that is dealing with the potential problem that is now a real problem, than I need to understand the principle that was broken and fix the problem by restoring the principle.  Restoring the principle could mean going on a search for the right solution to the original problem, not just trying to fix the problem that is a result of breaking a principle.  This problem that broke the principle may just be the wrong solution that we thought was the right solution because we ignored our principles in the first place.

Hmmm, that’s an interesting thought.  Karen Greaves asked me if a re-write can be justified and I mumbled something about technology, etc.  What tripe!  Now I think I’ve just reflected on when a rewrite is justified.  When refactoring will not fix the broken principle, then the right solution was never discovered in the first instance.  That is also what I mean when I say that clean code is necessary by not sufficient.  At factor10, we call this a radical makeover.  Radical makeovers are a viable way of getting rid of real problems, and restoring principles.

Heck!  This blog post is less about technical debt metaphors than I thought.  Oh well, the ride on this journey never stops.

By the way, a huge thank you to Steve for helping me realise that all problems come from breaking principles, in code and in life.

Patterns at the September SPIN Event

Posted on by

I suspect that many people did not understand what I meant about forces at play and that patterns describe a solution to bring some harmony among the forces in the problem in a particular context.  For the example of the airplane and wanting to serve the right meal to the right person, the challenge is to serve the meal without knowing about the seating arrangement on the plane, and still sequentially access each seat.  Let’s look at how to get rid of the need to know the seating arrangement.
We start with the solution where we need to know the arrangement of seating and number of seats too.  BTW, it’s ruby code.

for row in (0..29) do # 30 rows
    for pos in (0..5) do # seat A-F
       passenger = airplane.seats[row][pos]
       next if passenger.nil?
       passenger.serve_meal("nut free") if passenger.meal() == "nut free"
    end
end

Of course, if we know the seat number, for example, 15C, then we can do this.  But that does not help at all.

airplane.seats[14][2].serve_meal("nut free") if airplane.seats[14][2].meal() == "nut free"

But, we still expose the data structure of the seats.  So, let’s make it a little better by using the iterator pattern on the data structure for the seats.

airplane.seats.each do |row|
  row.each do | passenger |
    next if passenger.nil?
    passenger.serve_meal("nut free") if passenger.meal() == "nut free"
  end
end

We could be cuter and do something like this and hide the seats array, but we still expose the numbering scheme of the seating.

airplane.serve_meal("15C", "nut free")

So, we can have the iterator on the seats data structure, which helps a bit.  But we can make it a lot better if we put an iterator on the airplane itself. Now, we just care about occupied seats.

airplane.each_occupied_seat do |passenger|
  passenger.serve_meal("nut free") if passenger.meal()
 == "nut free"
end

In the airplane class, we have the following.

class airplane
  ...
  def each_occupied_seat &block
    @seats.each {|row| row.each { |pos| yield pos if not pos.nil?} }
  end
end

We are using iterators on the encapsulated seats structure and exposing a new iterator for the airplane. Also, we are only work with seat that has a passenger

So, we started out with a deep need to know the structure, layout and limits of the seating in the airplane. Then we started hiding the data structure for the seats, put iterators on this seats data structure which helped a bit.  But the real breakthrough happened when we started asking the airplane to just give us a way of sequentially accessing each seat that had a passenger.  No more conflicting forces, just a simple harmonious way to access each occupied seat on the plane.  And when the plane seating changes, we don’t care.

Balancing craftmanship and methodology

Posted on by

Carlo Kruger commented on my last blog post with reference to Martin Fowler’s blog post which is a concise view of a crazy blog and twitter war around software craftmanship.  For some reason, Carlo thinks that my last two blog posts (here and here) fall into this space. Either Carlo is baiting a hook for fun 😉 or he misunderstood me. Nevertheless, my dear friend, I shall reply.
Martin Fowler and Dan North put the customer’s derived value from the software as the focal point.  The craftmanship movement puts the code that derives the value as the focal point.  I don’t feel comfortable about either.  It is unbalanced.  We always need balance.  So, what will provide an equally powerful balancing force to either of these two focal points?  I think it is the economic viability of the code base.

In Let scrum die, the key message is that Scrum should not be the end goal but a means to get somewhere better.  At some point it will outlive it’s value and I propose a moment in time when that will happen, and one way to force this (i.e. plan the exit of the Scrum master).  I also describe “talented developers” which, perhaps, feels like a craftmanship-esque thing.  It’s not about that at all.  It’s about the balance that is described in the next to last paragraph: developers will represent the interest of the customer, and the code base is under control (i.e. it is economically viable).  Balance the focus of methodology with an the economic viability of the code base.

In You can’t let Scrum die, I draw attention to this lack of balance that leads to complacency.  I mention two craftmanship things to do with the code – remove duplication and express intentions.  Again, it’s not about this alone.  It’s about the balance that is needed.  That balance is described in the next to last paragraph: look at yourself and look at what you create (i.e. the code base).  The reason why I say look at the person next to you is because the economic viability of the code that you create will affect that other person also, including the entire organisation and its customers.  Balance the craftmanship with the methodology which is balanced by the economic viability of the code base.  This reduces to balancing craftmanship with the economic viability of the code base.

There is one area where I don’t know of a powerful enough balancing force.  In Politics of Software Delivery, I draw attention to organisational power grabbing that will always result in non-delivery.  I suggest raising the importance of the delivery value.  But I think this is still too weak a force to balance the power battle.  I don’t know how to fix that one.

Footnote: Jimmy Nilsson reminded me of an article he wrote about why TDD, Refactoring, DDD, and all such things matter.

Lean Software Development Webinar

Posted on by

I will be joining Kent Beck and Henrik Kniberg on July 20, 2011 for an SD Times webinar on Lean Software Development.  As usual, Kent has put up a great abstract for the event.  I’m absolutely certain that Kent will set the scene with his usual deep insights, and Henrik  has some amazing “from the trenches” experiential material to share.  Overall, we will explore this concept of waste vs value and how lean influences application development.
Personally, I want to cover what flow and waste mean to me, and examples of the huge piles of waste that I ended up manufacturing or walking into blindly and then struggling to dig myself out at great expense.  If the time allows, I want to weave in some models of flow that work for me and those that contributed to waste.  All of this fits into my rather weak thoughts on designing feedback loops.