Kerry Buckley What’s the simplest thing that could possibly go wrong?

Only a couple of years ago a source code management system, as far as I was concerned, was somewhere you checked files out of when you started development for a release, and checked them back in a month or two later. Integration was something that generally occupied the next few weeks, as everybody’s changes fought amongst themselves over who could find the most interesting ways to break stuff.

Yesterday we had a major power fault in the server room where our Subversion and CruiseControl boxes (amongst a lot of much more important stuff) lives.

It’s surprising how much of a pain it now seems not to be able to commit code as I get it working. Not to be able to integrate other people’s changes. Not to be able to check that my code passes all the acceptance tests in a controlled environment.

At least it’s not like the old days when we had to actually do all our development on the Unix server, so I can still get on with things until it’s all sorted out.

Aha! It seems that while I was typing this post, the repository has come back online.
[tags]continuous integration[/tags]

Josh Evnin writes in Agile anti-pattern: Developer-focused retrospectives:

In a retrospective, however, it is important that no one group of team members is favored over others. This is harder than it may seem, especially when the developers make up more than half of the team.

The way most retrospectives I’ve been a part of have worked is some variation of the following:

1. Individuals think of a few things that have gone well, and a few things that have gone less well over the past set time period
2. These thoughts are put on post-it notes, then placed on a wall
3. Individuals read all the thoughts and vote for the ones that they agree with (each person has a limited set of votes)
4. The retrospective facilitator tallies the votes and discusses the highest vote-getters with the team, and discusses ways to fix problems and continue successes

Now, as you can tell this is a quite democratic process. The problem is, when the ratio of developers to business analysts is 4:1, you start to see the topics discussed err towards the technical.

I wonder whether concentrating on one role’s issues is also a symptom of not having retrospectives often enough.

Of course there’s a place for project or release retrospectives, but I tend to find more frequent iteration/sprint retrospectives more useful, as they give you a shorter feedback loop. As a side-effect, there are usually fewer things to add to the list after only one or two weeks, so we have time to discuss anything that gets raised, rather than having to pick the most important.

One of the persistent themes in my team’s retrospectives is that we don’t pair as much as we should. It’s not that we don’t want to pair, or that something’s stopping us: we just seem too often to lack the discipline to start pairing and then not drift back into working alone again. I’m not sure the best way of avoiding the delay in forming pairs at the beginning of the day and after lunch¹, but here’s at least one tip to keep the sessions going.

If you need to quickly nip back to your own machine to check some documentation, google something, check for some urgently-awaited e-mail reply or whatever…

Don’t take your chair with you.

¹I think this is a variant of the ‘one more pint effect’ that’s often observed when a group over a certain size meets in a pub prior to going for a meal. One person decides that everyone’s going to take ages drinking up, so they decide to have ‘one more pint’. Of course, someone else then sees them with a full glass, and makes the same decision, and you end up arriving in the restaurant an hour later than planned. The pairing equivalent is where you all think ‘everyone looks busy, so I’ll just [answer that e-mail | do that pointless mandatory on-line training course | go and make a coffee] while I’m waiting for someone to pair with’.

Of course the real answer is to be strict about all production code being pair-programmed, rather than letting yourself make exceptions for ‘trivial’ tasks, or UI code, or refactoring, or something that started as a spike but has somehow grown tests and made it into the trunk…

From the slightly-odd The Way of Testivus, via InfoQ:

The pupil asked the master programmer:
“When can I stop writing tests?”

The master answered:
“When you stop writing code.”

The pupil asked:
“When do I stop writing code?”

The master answered:
“When you become a manager.”

The pupil trembled and asked:
“When do I become a manager?”

The master answered:
“When you stop writing tests.”

The pupil rushed to write some tests.
He left skid marks.

If the code deserves to be written,
it deserves to have tests.