markhneedham/blog huggingface dataset:
Distributed Agile: Communication - Reliance on one person
Date: 2010-11-08 13:56:21

Continuing with http://www.markhneedham.com/blog/category/distributed-agile/[my series of observations on what it's like working in a distributed agile team], another thing that I've noticed is that it's useful to try and ensure that there is communication between as many people as possible in the two cities.

This means that we want to ensure that we don't have an over reliance on one person to handle any communication.

We have a call once a day between developers in Pune and Chicago and the Chicago guys have been able to achieve this by rotating the person attending the call.

In Pune we've typically had half the developers attending the call but perhaps only one or two actually speaking.

I originally didn't think of this as being a problem because those two guys were really good at communicating and in other teams I've worked on we'd typically have the tech lead and maybe one other communicating with other teams.

In this case we are communicating with people in the same team and by chance a few weeks ago both of the main communicators from Pune were away at the same time so we had to have the Chicago call without them.

Perhaps unsurprisingly others were able to fill the gap that had been left and as an added benefit the guys in Chicago had now had the opportunity to interact directly with more people from Pune.

A interesting and positive side effect I've noticed is that the people who had now started communicating directly with team members in Chicago seemed to become more involved in the project as a whole and are now also more likely to communicate via email than they may have been previously.

Our challenge now that both the original guys are back is to ensure that the whole team still remains involved in communication with Chicago and don't delegate back to those two every time.
Retrospectives: General observations
Date: 2010-11-06 17:17:16

Following on from http://www.markhneedham.com/blog/2010/11/06/retrospectives-actions/[my blog post about some observations about the actions that we create in retrospectives] I've also noticed some general ways that retrospectives might not end up being as useful as we'd hope.

== Having a manager facilitating

While having the manager of the team facilitating the retrospective isn't a problem in itself I think it's useful to remember that in this context they aren't in that role anymore.

I've noticed that there can be a tendency for people to direct any comments they make during the retrospective towards the manager, thereby excluding others from the conversation.

Having the facilitator call out their role at the beginning of the retrospective and encourage participants to address any comments to the group can help to counter this situation.

== Facilitator participating

Another closely related pattern is that of the facilitator participating in the retrospective and it's easy to see why it happens since if the facilitator is part of the team then they probably have some opinions that they want to share as well.

Unfortunately what I've noticed happen is that they end up giving their opinion on the points made by others and if they have an opposing opinion to someone then it can easily discourage that person from participating any more.

One way to get around this problem is to have an external facilitator and the other is for the facilitator to realise that their role in this meeting is to facilitate and keep their opinion to themself!

== Collecting/Analysing information

Another common problem I've seen is the attempt to try and combine the collecting and analysing of data for the iteration.

I find that the problem with doing this is that we can easily end up belittling people's observations if they get analysed and dismissed without being written up on the whiteboard.

Collecting all the data as one activity and then working through it after everyone's had a chance to make their contribution is a much more effective way to do it.

== Focusing on things out of the team's control

While it's useful to identify things that are going wrong which are out of our control it can quickly get very boring for everyone if those things get brought up repeatedly.

Quite often we don't have the ability to address some things straight away but once we've gained a bit more trust we might get the chance to in future.

We've sometimes had retrospectives where you were only allowed to bring up things which could be addressed by the people in the room and this worked reasonably well.

It is still useful to remember which things we want to try and chance but can't at the moment so that we can try again in a couple of months time.
A dirty hack to get around aliases not working in a shell script
Date: 2010-11-24 18:48:25

In another script I've been working on lately I wanted to call 'mysql' but unfortunately on my machine it's 'mysql5' rather than 'mysql'.

I have an alias defined in '~/.bash_profile' so I can call 'mysql' from the terminal whenever I want to.

[source,text]
----

alias mysql=mysql5
----

Unfortunately shell scripts don't seem to have access to this alias and the http://unix.ittoolbox.com/groups/technical-functional/shellscript-l/how-to-use-an-alias-in-shell-script-2076287[only suggestion] I've come across while googling this is to source '~/.bash_profile' inside the script.

Since others are going to use the script and might have '~/.bashrc' instead of '~/.bash_profile' I didn't really want to go down that route.

At this stage a colleague of mine came up with the idea of creating a soft link from mysql to mysql5 inside a folder which is already added to the path.

We located mysql5...

[source,text]
----

> which mysql5
/opt/local/bin/mysql5
----

...and then created a soft link like so:
[source,text]
----

cd /opt/local/bin/mysql5
ln -s mysql5 mysql
----

And it works!

Of course t'is pure hackery so I'd be interested if anyone knows a better way of getting around this.
Ruby: Checking for environment variables in a script
Date: 2010-11-24 18:34:45

I've been working on a Ruby script to allow us to automate part of our http://lucene.apache.org/solr/[Solr] data setup and part of the task was to check that some environment variables were set and throw an exception if not.

I got a bit stuck initially trying to work out how to return a message showing only the missing environment variables but it turned out to be pretty simple when I came back to it a couple of hours later.

So for my future reference than anything else, this is what I ended up with:

[source,ruby]
----

  variables = %w{VARIABLE_1 VARIABLE_2}
  missing = variables.find_all { |v| ENV[v] == nil }
  unless missing.empty?
    raise "The following variables are missing and are needed to run this script: #{missing.join(', ')}."
  end
----

I recently came across '%w' which creates a string array out of the values that we specify.

In this case we therefore end up with...

[source,ruby]
----

> %w{VARIABLE_1 VARIABLE_2}
["VARIABLE_1", "VARIABLE_2"]
----

...which I think is pretty neat!

The other neat method is 'join' on line 4 which concatenates all the elements of an array while putting the provided separator in between each element.

In this case if we had neither of the variables specified we'd end up with the following:

[source,ruby]
----

> ["VARIABLE_1", "VARIABLE_2"].join(', ')
"VARIABLE_1, VARIABLE2"
----
Systems Thinking: Individuals and the environment
Date: 2010-11-23 20:20:03

Something which I've become fairly convinced about recently is that the environment that someone works in has far more impact on their perceived performance than their own individual skills.

Given that belief I've often got stuck answering why some people are better able to handle a difficult environment than others - in terms of accepting the situation and finding a way of being productive regardless.

Does this mean that they're better than people who can't work in that environment as effectively?

That's certainly a judgement that I've made previously but after discussing this with http://twitter.com/#!/dtsato[Danilo Sato] over instant messenger and http://twitter.com/#!/patkua[Pat Kua] & http://twitter.com/#!/estherderby[Esther Derby] over twitter I can now see that I'm more than likely wrong.

Danilo pointed out that *it doesn't actually means that they're better, it just means that they're better at coping*.

If we work on improving the system then perhaps we can allow everyone to work more productively.

http://twitter.com/estherderby/status/6407180727091200[Esther] has a similar view:

____
@markhneedham Sure. ppl have different ways of coping. Why not improve the system so everyone can do better?
____

And Pat http://twitter.com/#!/patkua/status/6405733037899778[adds] http://twitter.com/#!/patkua/status/6405912939986944[the following]:

____
@markhneedham different strengths and interest at play. Emergent behaviour based on individual and environment
____

____
@markhneedham also people have different coping mechanisms and thresholds for tolerance/intolerance
____

Prior to this conversation I somehow hadn't considered the benefits we can get from putting people in environments which allow them to play to their strengths.

I think we do this reasonably well when interviewing where one of the key criteria is to consider whether the candidate would enjoy working in the organisation's environment.

Beyond that perhaps not so well because it's implicitly assumed that whoever is hired should be able to operate effectively regardless of the environment.

Pat also pointed out that while it is good to work out how to get people into their optimal environment we shouldn't forget that, as difficult as it may be, *improving the system we're currently working in can also be effective*:

http://twitter.com/markhneedham/status/6408946596188160[Me to Pat]:

____
@patkua ok so it sounds like what you're saying is we should look to try and place people in environments which are best suited to them
____

http://twitter.com/#!/patkua/status/6461463401070592[Pat's reply]:

____
@markhneedham I'm saying that's one possibility. Changing the system is another. We should be pursuing both strategies.
____
Experiments in not using the mouse
Date: 2010-11-12 15:43:37

http://twitter.com/#!/priyaaank[Priyank] and I have been pairing a bit lately and we thought it'd be interesting to try and not use the mouse for anything that we had to do while pairing.

== Editor

Priyank uses http://gvim.en.softonic.com/[GVim] (http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convince-me-to-use-vim-was-wrong/[Yehuda Katz] recommends http://macvim.org/[MacVim] if you're using Mac OS) so we already don't need to use the mouse at all when we're inside the editor.

One annoying thing we found is that sometimes we wanted to copy stuff from the terminal into GVim and couldn't think of a good way to do that without selecting the text on the terminal with a mouse and then 'Ctrl-C'ing.

A bit of Googling led us to the http://www.vergenet.net/~conrad/software/xsel/[xsel] command which takes standard input and makes it available on the clipboard.

For example we've been using http://www.grymoire.com/Unix/Sed.html[sed] and wanted to copy the code we'd been spiking into a shell script:

[source,text]
----

# code to replace backslashes with pipes in a file
echo "sed -i 's/\\/|\g' some_file.text'" | xsel -bi
----

In OS X we have 'http://prefetch.net/blog/index.php/2009/02/13/pbcopy-pbpaste-in-os-x/[pbcopy]' which allows us to do the same type of thing.

Once we've got that onto the clipboard we need to use 'Ctrl R' followed by '+' in order to paste into GVim.

The next step is to get away from having to use the arrow keys which are annoyingly far away from all the others on a full sized keyboard but we're not there yet!

== Browser

We're using Chrome so Priyank has installed the http://vimium.github.com/[Vimium] extension which allows us to use Vim shortcuts inside Chrome.

So far I've only been using the 'f' command which gives you key combinations to click on any of the links on the page but it's still much more fun than having to scroll around with the mouse!

If anyone has any other tips or tools for us to experiment with that'd be cool to hear about - it was much more fun constraining ourselves slightly and seeing how we got on!
Make it interesting for yourself
Date: 2010-11-22 19:58:21

Just over a year ago I wrote a post about http://www.markhneedham.com/blog/2009/10/03/learn-one-thing-a-day/[learning one thing each day] and since I've been struggling to do this lately I thought I'd come back to this topic again.

My general thinking at the time I wrote that post was that sometimes it would be really difficult to find a way to learn anything on the project I was working on and the only way to learn would be to play around with something outside work.

While I still think it's useful to learn new things I'm moving towards the opinion that we have more chance of making things interesting for ourselves and therefore create opportunities to learn than we might imagine.

The underlying idea is that *if it's boring and repetitive then find a way to make it interesting*.

For example, I've been working on some cucumber regression tests today and I know that I can easily write the scenarios out manually but it's incredibly boring and unchallenging for me to do that.

I therefore decided to see if I could construct a cucumber table of the fields to be filled in by using jQuery to find all the field names on the page and then printing them out to the console with the appropriate values before pasting it into the cucumber scenario.

The next step is to see whether it's possible to record a scenario with Selenium IDE and convert that into a Cucumber scenario, assuming that's not already been done!

It's certainly not as productive initially as just writing out the test manually but it's much more interesting and potentially saves time in the future.

I think it's much better to take this type of trade off than to just mundanely go through what we're doing with minimal motivation.
Coding: Write the first one ugly
Date: 2010-10-03 05:03:44

I just came across a really cool blog post written a couple of months ago by Evan Light where he proposes that we 'http://evan.tiggerpalace.com/articles/2010/07/26/write-the-first-one-ugly/[write the first one ugly]':

____
To overcome paralysis, for small chunks of code, it is often better to just write whatever comes to mind -- no matter how awful it may seem at the time. Give yourself permission to let the first version suck.
____

I think this is a really good piece of advice and it seems along the same lines as a http://www.markhneedham.com/blog/2008/09/15/clean-code-book-review/[suggestion from Uncle Bob in Clean Code]:

____
When I write functions they come out long and complicated...then I massage and refine that code, splitting out functions, changing names and eliminating duplication...all the whole keeping the tests passing.
____

I find myself following a similar approach to Evan these days whereas previously I'd probably have spent a lot of time thinking through the problem in my head trying to come up with a design I was happy with.

I agree with Evan that it's frequently easier to see a clean way to solve a problem if you actually have some sort of code in front of you even if it is a terrible solution.

If I get stuck I tend to copy and paste other code, break encapsulation of objects, write long methods and so on. Then after I have something actually working I'll go back and clean it up.

Sometimes I don't see a way to write a piece of code more cleanly so I'll leave it alone until the next time we're working in that area of the code base, an approach that Joshua Kerievsky expands upon in a post he wrote a few months ago titled 'https://elearning.industriallogic.com/gh/submit?Action=PageAction&album=blog2009&path=blog2009/2010/sufficientDesign&devLanguage=Java[sufficient design]'.

I'll leave the final word to http://twitter.com/haruki_zaemon/status/26161884865[Simon Harris who made the following observation on twitter] which I think is pretty accurate:

____
Ive said it before the difference between great developers and hacks is: the former clean up after themselves.
____
Rails: before_filter, rescue_from and so on
Date: 2010-10-05 08:53:48

One thing I've noticed while browsing our Rails code base is that the first entry point inside a controller is much less frequently the method corresponding to the action than it would be with a C# ASP.NET MVC application.

The concept of filters exists in ASP.NET MVC but on the projects I've worked on they've been used significantly less than before filters would be in a Rails application.

As a result I'm getting much more in the habit of checking for the before filters in the ApplicationController when an action isn't working as expected to try and figure out what's going on.

One which caught us out the other day is the 'rescue_from' method which gets mixed in from Rescuable.

Every single time we tried to login we were just getting redirected back to the login page again with no exception being reported anywhere.

Eventually we realised that the InvalidAuthenticityToken exception was being thrown because we somehow had a different token stored in our browser's cookie than was in the form.

Since our LoginController extends the ApplicationController, the following logic was being used to handle the exception:

[source,ruby]
----

class ApplicationController < ActionController::Base
   rescue_from ActionController::InvalidAuthenticityToken, :with => :redirect_to_referer

  def redirect_to_referer_or_path
    redirect_to request.referer
  end
----

We initially didn't spot it because it was hidden away between a whole load of other before filters and includes of modules.

The convention as far as I can tell is to try and keep as little code as possible inside the action method and handle common logic - such as looking up a user based on an id or handling exceptions - in filters.

It helps to keep the code inside actions pretty clean and remove duplication but I just need to remember to check both the action and the top of the class for any filters when investigating problems.
Learning: Writing about simple things
Date: 2010-10-20 20:51:56

My colleague http://www.wikyblog.com/AmanKing/[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 http://www.markhneedham.com/blog/category/dotnet/f-dotnet/[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 http://www.markhneedham.com/blog/2009/05/02/f-stuff-i-get-confused-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 http://www.markhneedham.com/blog/2009/04/21/learning-through-teaching/[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 http://www.markhneedham.com/blog/2010/10/16/ruby-hash-default-value/[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 'http://www.wordyard.com/2010/10/08/blogging-empowerment-and-the-adjacent-possible/[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.
Distributed Agile: Physical story wall still useful
Date: 2010-10-20 17:21:24

When I started working on my current project there was no physical story wall, instead the whole project was being tracked on http://www.thoughtworks-studios.com/mingle-agile-project-management[Mingle].

The current state of the Mingle story wall was sometimes visible on a shared monitor and sometimes wasn't, depending on whether or not the monitor had been turned off.

There was also a small wall used to track which stories were in development but after that there was no physical visibility of the status of anything.

The advantage of this approach was that there was no need to have the overhead of having to maintain a physical story wall and an electronic one.

The disadvantage was that it was quite difficult to see what people were working on and there was a very definite split between development and testing.

Mingle and similar tools are useful in distributed teams but they are information refrigerators in the sense that you have to put in some effort in order to get information from them - it's not immediately available to you.

The physical story wall on the other hand is an http://alistair.cockburn.us/Information+radiator[information radiator] which is what we want!

In the case that we get around that problem by using a projector to beam the web page onto a wall I still don't think it's as effective because it's  less human to deal with a projection than a real card wall.

I find it's much more effective for people to be able to move cards around with their hands and then move people in between those cards depending on what pairings make sense at any given time.

The collaboration on my team seems to have increased quite dramatically since we made the card wall physical and I'd be surprised if the overhead of updating Mingle and the story wall was more than 5 minutes per day.