My colleague Chris Johnston wrote recently about his experiences in agile software development, posing some questions that he has.

Specifically:

Now I’m assuming that most (if not all) of Chris' experiences with agile have been at ThoughtWorks, in which case the mix of agile we use on our projects tends to be a combination of Scrum and Extreme Programming.

The last question seems the most logical to start with:

I’m with Chris on this one - as far as I understand agile is all about adapting a set of principles to the environment that we find ourself in. It’s unlikely that the exact same approach will work in two different projects.

I’ve worked on 6 or 7 projects at ThoughtWorks and each has taken a slightly different approach to agile, varying the amount of process we use, the amount and type of tracking done, the approach to gathering requirements, and so on.

Our client’s wishes, the availability of the business, the number of integration points, the size of the team, are all things that will influence the approach that we end up taking.

Extreme Programming (XP) defines a set of practices that we can use on an agile project although there are certainly other approaches that are equally valid.

Pair Programming is one of the XP practices rather than something you need to do in order to be 'agile'.

I’ve worked on teams where we haven’t paired, teams where some people on the team pair and teams where everyone does pair all the time but I wouldn’t say as a rule people have to pair all the time.

When a team is responsible for the delivery of some software pair programming is the best approach that I have worked with for ensuring that people on the team have a good understanding of all areas of the code base.

While someone working alone in 'flow' might be able to write some brilliant code, noone else on the team knows anything about that code meaning that the knowledge of the implementation takes longer to work its way to the rest of the team.

I don’t think design is evil and again all the teams I’ve worked on have done some design work up front, it would be fairly foolish not to.

Finding the balance between over architecting up front and doing just enough design to allow us to keep moving forward is the key here.

I’ve previously written about the dangers of commenting code so I don’t want to revisit that too much, suffice to say that it it usually possible to describe what you want to in a comment using an appropriate method name instead.

My experience with comments is that they go out of date more quickly than code does and therefore can end up being misleading to someone reading the code.

The only real time I have seen a valid use for them is when used to describe a problem the code is getting around where the explanation is fairly verbose and can’t be expressed easily in code - for example, when using one of the jQuery validators there was some strange behaviour with regards to the behaviour of the plugin when different options were set.

For a while we didn’t put a comment and others in the team would change the code not realising that it would cause a problem.

With the comment in place people have a better context before they make a change.