My Event Horizon

It’s already halfway through the year, so let’s see what events are is in store for the rest of the year.
June: Next week is SPIN week.  Join us after the June 16 public holiday.  Same time, same place.  Last month we had 40 people attend and we just about ran out of chairs.  Lots of new faces.  Please come along.  The talks are normally good and the conversations are great.

July: Really need to get my act together and get to the next SA Developer‘s talk.  Hilton Giesenow tells me it’s a great local event.  And On July 27, Lia turns 5!  Simply amazing!

August: Hmmm, seems quiet?  I think I’m going to submit a tutorial proposal for the ICSE conference happening in Cape Town in May 2010.

September: Looking forward to the Scrum User Group‘s conference in early September.  I may be giving a talk on the techie track.  I think it’s going to be a great event.  Carlo and Peter tell me so.  But on September 3, Fiona turns … older 😉

October: My tutorial on using DDD and AOP to create clean, rich domain models has been accepted by OOPSLA.  So, October is OOPSLA time for me.

November: I will miss Oredev.  The competition to get in was so much tougher.  That just means it’s going to be better than last year.  If you’re a S.African developer, you should make a plan to get there.  It’s a great event that is very high on value for money.  But my November highlight is Khaleel turning 9 on the 22nd!  Boy, how did that happen so fast?

December: Crazy season again.  I really hope it’s a quiet, relaxing one this year.

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.

Enterprise Scrum and Killing the Stickman

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.

Discovering Language and Context

Last night, I attended the 43rd Cape Town SPIN meeting that turned out to be a fun, interactive exercise with John Gloor. John introduced a system of analysis which focused on modeling a domain – but not from and object oriented paradigm. It was more about “things” and “influences”. I am really doing a bad job of using the right terms, but let’s just try something out.

  1. As a group define (frame?) your problem domain (We chose “How to be a successful team”)
  2. Then individually…
    • write down as many thoughts about the domain as possible – short snippets of 3-8 words each.  The recommendation was to aim for about 70 thoughts.
    • Color code (or group) these based on some notion of similarity.
    • Give each group a name or label on a post-it
  3. Then as a group …
    • the first person sticks their post-its on the wall
    • each other person, in turn, then sticks their post-its up and aligns it with whatever else is already on the board (or creates a new spot altogether)
    • Optimize the emerging clusters and give them names
  4. Finally, put directed lines between the named clusters using the guide of “A influences B” and give the line a label as well.

We never had the time to get to complete step 6.  But the really interesting angle for me was that a language for the domain was emerging.  It was not perfect, but it was a nice start.  Secondly, some of the clusters felt a lot like strategic contexts.  Sure, it was a conceptual decomposition of sorts, but it may well be a nice starting point for discovering bounded contexts.

And those influence lines felt like dependencies and interactions between contexts.  The use of the word “influence” is a really nice alternative to the traditionally naive terms like “uses”, “has”, “is like”.  It naturally focuses on behavioural interactions.

So, this simple exercise may be a nice technique for discovering language and contexts within a domain.  And it proves to me, yet again, that language is most critical.  This is not just about maintaining a lifeless glossary of terms – but the energy surrounding the vocabulary and terms need to be depicted and felt as well.  And if we combine all of this with an agile mindset, we can adjust this “language model” with each iteration and gain deeper domain understanding continuously.  Hmmm, this notion of “language model” is intriguing!

Patterns at the September SPIN Event

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"

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"

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"

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?} }

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.