Mark Needham

From my last couple of months working for ThoughtWorks in Pune I think the most common subject that I’ve heard discussed is how to ensure that the team offshore is receiving all the context about the decisions and direction being taken onshore.

What I’ve found most interesting is that I think out of all the teams that I’ve worked on in the last four years my current team has by far the most context about what the client wants to do and the approaches they want to take over the next few months.

I think the main danger of trying to provide this level of context is that it almost inevitably leads to over communication.

Three of my colleagues from Pune recently went to Chicago for a few weeks and having returned to Pune want to share the context they got in Chicago with us.

I’m a fan of pulling information when you actually need it so my preferred approach was to discuss each of the functional areas closer to the time that we’d actually be working on it rather than having the guys effectively do a brain dump on everything they’ve learnt right now.

My reasoning is that I find that I struggle the most to learn when someone gives me a whole load of information which I can’t really connect to anything – i.e. information out of context.

The new design of ThoughtWorks University provides an example of how learning in context can be very effective.

Interestingly I was significantly outnumbered by my colleagues when we voted on which approach to take. They preferred to receive the context up front rather than later on.

I decided to go to a few of the sessions anyway and while the context has been well presented, I am finding that I forget the specifics of those sessions pretty quickly since I don’t have anything to link the concepts to nor am I using the information I’ve learnt right now.

I’ve also noticed less and less people attending these sessions for similar reasons.

My opinion on this type of thing is that as long as I know where I can get the data from when I need it then that’s enough. I don’t need to have all the details up front.

I’m not sure if this observation has anything to do with the team being offshore, if it’s a cultural thing or none of the above.

It’d be interesting to hear about others’ experiences.

As I’ve mentioned on twitter a few times my current team has a lot of meetings and apart from using the passive aggressive approach that Toby Tripp’s meeting ticker provides I’ve also been flicking through Chapter 19, ‘Guerilla Collaboration’, of Jean Tabaka’s ‘Collaboration Explained: Facilitation skills for software project leaders‘ which gives other ideas.

I’ve also seen some useful ideas that my colleagues have used in meetings that I’ve been part of.

Agenda/Purpose of the meeting

Jean suggests that we ask the meeting organiser for an agenda in order to ensure that:

• We aren’t wasting the time of some participants
• We aren’t missing any important attendees
• The meeting has a focus and people aren’t at a loss for what to do

I’ve noticed the 1st and 3rd of these happening more frequently and it’s typically because the topic of the meeting is very generic which means that anything goes!

Time Check

Calling for a time check is useful for helping ensure that the time in the meeting is being used effectively and that the meeting doesn’t over run the allocated time.

Having a start and end time for the meeting is also useful because otherwise a meeting can drift on for hours without any conclusion.

Creating a constraint – of time in this case – helps to keep things a bit more focused and in theory could lead to move creativity.

Keeping the discussion on track

This is typically easier for the meeting facilitator to do but it’s certainly possible for an attendee to ask whether a certain discussion is relevant or if it can be taken offline.

I find that discussions can often drift into implementation detail i.e. the wrong logging level and totally isolate the majority of the meeting’s participants.

It’s certainly important to be careful when doing this because you might be wrong about what ‘on track’ means and people can quickly stop contributing if you consistently shut them down.

Parking lot

This would typically just be a section of the whiteboard used to ‘park’ discussions about topics which we can get to later but aren’t part of the purpose of the meeting.

I haven’t seen this used that often but it seems like a useful technique because it still acknowledges that someone has a valid point, just that it’s not for discussion at the moment.

I managed to create an interesting problem for myself while playing around with some code whereby I was ending up with validation errors appearing twice every time I called ‘valid?’ on a specific model.

I figured I was probably doing something stupid and in fact a few replies by Aaron Baldwin on a mailing list thread on ‘rubyonrails-talk’ helped explain exactly what I’d done:

Are you calling require ‘employee’ anywhere? If so you are likely
causing the model to load twice which causes duplicate errors because
the validates_presence_of method gets called twice.

I’d put the following code into a controller elsewhere somewhat unnecessarily since it didn’t seem to be picking up the location of my model at the time:

code_submissions_controller.rb

require 'models/code_submission'
 
class CodeSubmissionsController < ApplicationController
  def new
    CodeSubmission.new  
  end
end

require doesn’t load a file if it’s already been included but Aaron points out why it does on this occasion:

You are right that “require” will only load the file once. But if you load the class another way calling “require” will load it again.

As I understand it that controller code would also implicitly require ‘code_submission’ by the convention of inserting an underscore between the ‘CodeSubmission’ constant’s names.

We therefore effectively have the following two requires:

require 'code_submission'
require 'models/code_submission'

Which explain how the file gets loaded twice and therefore why the validation method fires twice and therefore creates two errors!

We’re using Web Mock on my current project to stub out some of the external web requests in some of our integration tests and I managed to get myself very confused while trying to use a variable inside a regular expression that I was trying to pass to the ‘stub_request’ method.

The code was roughly like this:

some_url = "http://service.com/method"
 
stub_request(:any, /some_url/).
        to_return(:body => File.new('/path/to/some.xml'),
                                      :headers => {'Content-Length' => 666, 'Content-Type' => 'text/xml'},
                  :status => 200,
                  :headers => {'Content-Type' => 'text/xml'})

The request was being stubbed when I hard coded the url inside the regular expression but not being stubbed when I used the variable like in the example above.

I somehow missed the blindingly obvious in hindsight solution of treating variables inside a regular expression as if they were being used in a string.

If we wrap the variable inside ‘#{}’ then our problem is solved:

some_url = "http://service.com/method"
 
stub_request(:any, /#{some_url}/).
        to_return(:body => File.new('/path/to/some.xml'),
                                      :headers => {'Content-Length' => 666, 'Content-Type' => 'text/xml'},
                  :status => 200,
                  :headers => {'Content-Type' => 'text/xml'})

I still can’t quite believe I didn’t spot it straight away.

I’d always heard that communication when you’re working offshore was much more difficult than in a co-located team but it’s quite difficult to imagine exactly what the difficulties are until you see them for yourself.

These are some of my latest observations in this area so far.

Learning models

I’m a very visual learner and the majority of the time any communication between people in two different locations will be done through words either via email or on a conference call.

Of course it is possible to do remote white boarding but that increases the overhead of the calls and sometimes participants in these calls only have their phone available and don’t have access to their computer or the internet.

I tend to find myself sketching out conference call conversations on a white board so that I can follow what people are talking about.

You lose the instant feedback that you get when doing this with someone else but I find it easier to understand diagrams than paragraphs of text or dialogue describing something.

Duplication of discussion

Due to the fact that we can’t just grab everyone in the team and go into a room for 20 minutes to discuss a design approach because half of the team is in another city.

We often end up having a meeting in Pune and then a similar one later in the day over the phone with people onshore and a parallel conversation going on over email at the same time.

It’s been significantly more difficult to get consensus on any decision with this style of communication than it would be if everyone was in the room.

In that environment you can easily read body language and see if someone doesn’t quite buy into what is being suggested.

Thinking how to phrase it

I think this is just generally a skill which requires more skill in non face to face communication and the conversations tend to be much more sugar coated to avoid offending people.

I don’t think this is a bad thing but I find that face to face conversations can often be more direct without someone getting offended or spending time trying to work out if there was a hidden message in the other person’s communication.

The risk here is that we can end up spending a lot of time working out how to word our communication and lose the point that we were actually trying to make in the process.

Working with outside teams

If working with other people on the same team in a different country is tricky it becomes even more difficult when communicating with outside teams in the remote location.

For example we often have to interact with a client’s operations team and in a co-located situation someone on the team would probably have met people on that team personally.

In a distributed situation you don’t have that so if you have a request for them then you tend to communicate via email.

Since they only know you by your name on the email I’ve noticed that it takes significantly longer for things to get done than if you could just go and speak with them.

These are just some of the things I’ve noticed and I do admire my colleagues here for learning how to work effectively with these constraints because it’s been amazingly frustrating for me so far.

I think one of the most important skills to perfect when communicating with other people is to understand the level of detail that we need to be speaking at, something my colleague Ashwin Raghav refers to as our logging level.

We log various things in our code at varying logging levels ranging from ‘error’ through ‘debug’ to ‘warn’, and each of these is useful for understanding what our code is doing.

However, we might typically only report problems at the ‘error’ level unless something goes wrong and we want to try and understand in greater details what’s going on.

The same thing applies at a conversational level and I’ve noticed that the tendency is to zoom into the detail very quickly rather than staying at a high level.

In a group situation

While speaking at a detailed level is appropriate in some situations it can easily isolate people in a group situation if only one or two people are able to take part in the conversation at this logging level.

Given that it is possible to end up at the wrong logging level by mistake it then becomes important to watch the body language and reaction of other people in the group.

If they seem to be zoning out, losing interest or if the conversation excludes them then it’s fairly likely the logging level is too verbose and it would make more sense to take that conversation offline.

In a one on one situation

A similar thing applies in a one on one conversation but the way it rears its head is slightly different

When talking about code the tendency can be to talk at the syntax level in order to explain something.

For example if we’re talking about the merits of mocking or stubbing out methods on the system under test then the conversation has been set at a conceptual level and it wouldn’t make sense to start talking about the way that RSpec actually makes it possible to do this.

It’s also useful to work out the other person’s level of understanding so that we know what logging level our explanations need to be at.

We’ll typically get rapid feedback from the other person if we’re not doing this.

For example when I first started working with Ashwin my explanations were too detailed and he quickly pointed that out. That allowed me to jump straight to a higher level from then on.

The logging level that we’ll need to use will be different for each person and it does take a little bit of time to work out where exactly it needs to be.

I quite like Ashwin’s metaphor and I’ve been keeping it in mind when watching conversations and when communicating myself to try and ensure that the right logging level is being kept to for various conversations.

It is surprisingly easy to drift away from the optimal logging level though!

—-

As a side note it seems much less frequent that the people I work with speak at a level of detail which isn’t verbose enough and I can’t really explain why that is!

An approach to testing which I haven’t seen before and am therefore assuming is more specific to Ruby is the idea of stubbing or mocking out functions on the system under test.

I’ve come across a couple of situations where this seems to be done:

1. When stubbing out calls to methods which are being mixed into the class via a module
2. When stubbing out calls to private methods within the class

I think the first approach is fine because typically we’ll have a direct test against that module’s methods elsewhere and it doesn’t make much sense to test the same thing again.

I initially liked the second approach as well because it simplifies the spec we’re writing.

For example if we have this code:

class FoosController : ApplicationController
   def index
      populate_something
   end
 
   private
 
   def populate_something
      @something = Something.find(...)    
   end
end

Then by stubbing out ‘populate_something’ we can write a spec like this:

describe FoosController do
   it "should populate something" do
      controller.stub(:populate_something) # and so on
 
      get :index
   end
end

Rather than:

describe FoosController do
   it "should populate something" do
      Something.stub(:find) # and so on
 
      get :index
   end
end

This is a fairly contrived example of course and the temptation to stub out a method on the system under test increases as the amount of dependencies and the complexity of them increases.

The problem we create for ourselves is that if we want to change the internal structure of our class, perhaps by inlining those private methods, then we’ll end up with specs failing even if the external behaviour remains exactly the same.

My current thinking is that if we get in a situation where we want to stub out something on the system under test then it’d probably be better to listen to that pain and try and work out a cleaner way of solving the problem.

One of the things that I’ve noticed while working with various colleagues over the last few years is that the more experienced ones are much more skilled at making slight adjustments to their approach based on feedback that they receive from the environment.

I’ve been reading a couple of books on systems thinking over the last few months and one of the takeaways for me has been that we need to be careful when reacting to feedback we get from a system to ensure that we don’t over compensate and end up creating a new problem for ourselves instead.

The idea of over compensating is also know as ‘chasing the gauges‘ in the airline business where it describes the following situation:

When you roll on aircraft left or right. pitch it up or down, change the throttle or the brakes,t tokes time for the plane to “settle out.

Good pilots fly by making a change, then waiting a couple of seconds to see the results. If you don’t you’ll just “chase gauges” that are themselves still changing.

In terms of software development a mistake that I’ve made before is to see something go ‘wrong’ in a situation and then come up with a ‘solution’ to that which effectively means doing something completely different to what we’re doing now.

We had example of this on a project I worked on where we ended up doing a lot of re-work in one iteration because several people were working in a similar part of the code base and ended up trampling all over each other.

In the next iteration we had some stories which would touch a similar part of the code base and I thought it would make sense to split the work by front and back end rather than having each pair work on one story.

While this removed the re-work problem the unfortunate side effect was that it meant we had no visibility about either of the stories until one day before the end of the iteration.

A colleague pointed out that it might have been more effective to wait for a pattern to emerge before trying to make a correction.

In this case the solution probably didn’t need to be as dramatic as ensuring that people didn’t touch the same areas of the code base.

A more effective approach might have been to just have the pairs sitting next to each other and ensure that they communicated which bits of the code they were changing.

Tying that in with frequent commits would probably have removed the problem of re-work and still allowed us to keep the visibility of individual stories.

It takes a bit more discipline to not overcompensate and I think in a way it goes against the human instinct to try and fix a problem as soon as we see it.

I’m trying to move more towards the following approach:

• Wait and watch situations for longer before taking action
• Ensure any action isn’t too dramatic i.e. small steps
• Watch to see how the system responds to the change
• Try something else if necessary

It is difficult though and I certainly make a lot of mistakes.

I wrote earlier in the week about the benefits of having a physical story wall on a distributed team and in the process of getting one in place on the project we learnt a few things that I’d previously taken for granted.

All the work in one place

We initially started off by having stories on one part of the wall, bugs on another part and any technical tasks stored in Mingle somewhere.

The problem with this approach was that it wasn’t easy to glance at the wall from wherever you were sitting and be able to quickly gauge the state of the project at any given time.

We needed to look at one side of the wall to check what stories were being worked on and then check the other side of the wall to see who was working on bugs.

A couple of times we’d forget that the bugs were being tracked on the other side of the wall and two pairs would look at the same bug before realising that it had already been picked up.

We’re now in a place where we have stories, bugs to be fixed in this iteration and technical tasks all in the same lane on the wall.

Doing this means that everyone can quickly gain visibility into what can be worked on and then they can easily work out what the next thing to pick up is.

Proactiveness

I hadn’t realised the value of having upcoming stories visible on the wall in the ‘ready for dev’ column until I saw it not being done.

The proactivity of the team seemed much less than in previous teams I’d worked on because people were unaware what they could pick up once they’d finished working on a story.

As a result of this there tended to be a lot of time where developers were waiting around looking for something to do.

A bottleneck had been created where they would need to wait for an analyst to tell them what could be picked up.

Now a pair can what the next highest priority thing for them and pick it up or at least work out roughly what they need to do before running through it with an analyst.

My colleague Aman King is back in Pune for the time being and during one of our conversations he was asking me why I didn’t wait a bit longer and learn more about Ruby before writing about it.

In a way he is right and I didn’t write anything at all about C# or Java when I was first learning how to write code in those languages because I didn’t have the confidence to write about something that I knew nothing about.

However, what I found when I was initially learning F# was that even writing about very basic things was quite useful to me and once I’d written about something my understanding of it tended to increase.

For example about a year and a half ago I wrote a post about some common things that I’d been getting confused with and I was quite surprised to notice that I never confused them again once I’d written that post.

I’m not sure of the science which explains why that happens but I’ve noticed a similar thing happening with Ruby.

I wrote about the advantages of learning through teaching last year which is along similar lines and I think the points I made there are applicable even if the subject matter would be trivial for others.

The other useful side effect which sometimes happens is that someone much better than me will point out a better way of doing something than what I described and I can then use their approach in code I write in the future.

In a somewhat related article titled ‘Blogging, empowerment, and the “adjacent possible”‘ Scott Rosenberg recently described in more depth how writing about things can actually change the way we think about them.